docs: record current Chrome route recovery evidence (#188)

docs/research/peer-assisted-media.md

@@ -280,6 +280,18 @@ fanout stayed at two and relay fanout at one. This is control and continuity
 evidence only, not visual-quality, full-resolution, load, TURN, public-network,
 or endurance evidence.
 
+A 2026-08-22 current-release rerun at exact source `b77f4eb58944` used Chrome
+151.0.7922.138, three Viewers, the Host2/ordinary Browser Viewer1 policy, an
+eight-second sample window, and the existing hard-departure recovery gate. All
+three Viewers decoded; Host media fanout peaked at two, Browser relay fanout at
+one, and no SFU publication appeared. Closing the first-level relay page moved
+its affected descendant and resumed advancing frames in 5,380 ms while the Host
+remained within two media edges. The requested synthetic source was 1280x720 at
+30 fps, but observed final samples remained 320x180 at roughly 9-11 fps. This is
+real local `RTCPeerConnection` media and hard-participant-departure evidence. It
+does not exercise correlated bad-quality detection or provisional MBB, a silent
+socket partition, SFU, TURN, a public network, game capture, or resource quality.
+
 A 2026-08-21 local Chrome 151 capacity-two run used one Host and five Viewers
 with a synthetic 720p30 stream. Host and relay fanout peaked at two; one Viewer
 simultaneously served two children, whose inbound counters each advanced by 80

docs/verification-status.md

@@ -18,7 +18,7 @@ This is the demand-loaded ledger for cross-cutting validation evidence and open
 
 ## Retained Functional Evidence
 
-- Chrome 151 synthetic `1/3/5/8` and 720p30 runs preserved bounded fanout and decoding. Sixteen-Viewer cap2/cap3 loopbacks decoded all Viewers and a ten-second follow-up recorded guarded sender and aggregate Chromium CPU evidence, but resolution/FPS remained low and the ordinary-PC data cannot rank the caps. These are historical experiments that prove function, not sustainable capacity, heterogeneous-network quality, or authority to lift the Host2/ordinary Browser Viewer1 release policy. See [peer-assisted media](./research/peer-assisted-media.md).
+- Chrome 151 synthetic `1/3/5/8` and 720p30 runs preserved bounded fanout and decoding. A current-release three-Viewer rerun also kept Host2/Browser Viewer1, decoded every Viewer, and recovered a hard first-level relay departure in 5,380 ms; it did not exercise quality-triggered MBB. Sixteen-Viewer cap2/cap3 loopbacks decoded all Viewers and a ten-second follow-up recorded guarded sender and aggregate Chromium CPU evidence, but resolution/FPS remained low and the ordinary-PC data cannot rank the caps. These are functional experiments, not sustainable-capacity, heterogeneous-network-quality, or authority to lift the Host2/ordinary Browser Viewer1 release policy. See [peer-assisted media](./research/peer-assisted-media.md).
 - Chrome 151 with local LiveKit 1.13.5/client 2.22.0 proved one SFU/UDP root after `q,f` -> `q,h`: decoded frames advanced 3 -> 23, rendered frames reached 26, Host used one edge, leaves were clean, and TURN was absent. This is functional evidence only. See [low-server media routes](./research/low-server-media-routes.md).
 - Host A+B and authenticated P2P Viewer C evidence is sanitized, generation-bound, read-only, and closed for stale, ambiguous, or SFU-fed reports. Production can expose a Host-local current SFU `h` snapshot and clears it on publisher identity changes; raw media metadata is not retained. See [realtime quality adaptation](./research/realtime-quality-adaptation.md).
 - The built-in peer TURN canary was rejected after allocation passed but the direct Host/Pion Viewer path failed before forced relay. Full rollback restored STUN-only client ICE and zero allocations. See [built-in peer ICE TURN](./research/built-in-peer-ice-turn.md).