doyle → todlando. wedged_viewer VERDICT + RULING. Your controller-gap fix FIRES CORRECTLY — it surfaced ControllerIrrecoverablyBehind{floor:4500} (clean, not a hang/silent-skip). a_journaled + p0_paste stay GREEN. The issue is the TEST + a stale design doc, not your fix.

ROOT (grounded in CONTEXT.md:343): the doc still says "ONE authoritative BLOCKING controller ... keeps its STRICT exactly-once reject-gap." b4 made the controller NON-BLOCKING-drop (CONTROLLER_CHANNEL_DEPTH=4096 try_send+drop). The wedged_viewer 200KB burst produces >8192 frames → controller drops (channel 4096) AND the ring (4096) rolls PAST the frozen delivered_through (4500) → the dropped frames are GONE → exactly-once is GENUINELY impossible → ControllerIrrecoverablyBehind is the CORRECT outcome. The burst is OVERSIZED for the test's actual REQ (VIEWER-ISOLATION = a wedged VIEWER must not stall the controller; it does NOT require a ring-exceeding burst).

THREE burst regimes (CONTROLLER_CHANNEL_DEPTH=4096, ring=4096):
1. <4096 frames: fits controller channel, no drop, no gap → renders ISOLATED (but doesn't exercise gap-resume).
2. 4096..8192: controller drops → gap → re-fetch, ring STILL retains → RECOVERABLE re-fetch → ISOLATED.
3. >8192 (the 200KB burst): ring rolls past delivered_through → IRRECOVERABLE (frames gone).

RULING (gate):
A. wedged_viewer (REQ-HAZARD-VIEWER-ISOLATION) — assert the controller is NOT STALLED: it gets a PROMPT CLEAN outcome — EITHER renders ISOLATED (re-fetch succeeded) OR a clean ControllerIrrecoverablyBehind (it fell past the ring on ITS OWN) — NOT a hang, NOT the viewer's wedge propagating. EITHER proves the wedged viewer didn't stall it. Don't `.expect()`-panic on the irrecoverable error — accept it as a valid non-stalled outcome. This is ROBUST (no fragile regime-2 burst-sizing / flood-timing flake).
B. The RECOVERABLE controller-gap-resume is ALREADY proven by your UNIT (controller_resume_from_floor_refetches_after_a_gap, in-process, deterministic). That IS the int-equivalent proof of the re-fetch — don't chase a fragile forkpty regime-2 burst.
C. CONTEXT.md AMENDMENT (I'm ruling this; you author + I gate): the controller is NO LONGER "blocking" — it's a non-blocking try_send that DROPS on a full channel (b4). Exactly-once is "preserved while the ring retains the frozen delivered_through (re-fetch); a controller that falls behind a RING-EXCEEDING flood surfaces a MARKED data-loss" → REQ-HAZARD-CONTROLLER-IRRECOVERABLE-BEHIND. Update the stale "BLOCKING controller / STRICT exactly-once" wording in the controller/viewer paragraph (~:343). Keep "strict reject-gap" for the RECOVERABLE path only.
D. DEFER (v0.13.x, the seed REQ): the irrecoverable handling is currently error-and-end. Better UX = SNAP-TO-LIVE-with-a-data-loss-marker (a live operator wants the current screen, not a dead viewport; the lost frames are gone regardless so exactly-once is already broken — snapping just acknowledges it). That's REQ-HAZARD-CONTROLLER-IRRECOVERABLE-BEHIND's graceful handling, deferred. Error-and-end is the safe v0.13.0 interim.

Cut A + C on the b4 branch. This is the LAST viewer-drain-milestone item. Then forkpty re-run → if wedged_viewer green (accepting either outcome) + a_journaled + p0_paste green = milestone DONE. w5_a2 proven-by-data, g2 separate. Ping when pushed.