re: the mission black-screens at ~4.5 min — that is what ends every run

A two-segment OB watch made the mechanism visible. Segment 1 ran clean, with the
witness reporting zero stalled samples of fifty and OB steady at 4 for 250
seconds. Segment 2, attaching to the same still-alive emulator, got "NOT IN A
MISSION (no unit definitions)".

The emulator was alive; the mission was gone. The pilot's hull reads 1500 in
every line, so the player never died. Its log stops at t=267 s with consecutive
byte-identical lines, the freeze signature. And the screen is now entirely
black, mean (0,0,0). This is the pre-existing mission-end black-screen freeze
already recorded in the corpus, caught in the act. Segment 1's clean witness is
not a contradiction, since it sampled to about 250 s and the freeze came at 267.

That corrects an earlier claim. mission-arrival-watch.md records the blocker as
removed because the emulator survives between calls, which is true, but it was
stated as though observation could be extended indefinitely within a turn. The
emulator surviving is not the mission surviving. The binding limit is the game's
own black-screen at roughly four and a half minutes and no amount of chaining
crosses it. The earlier chained run that reached 435 s of cumulative
verified-live observation did so across two segments of one mission, which fits:
its second segment froze at t=135 s.

The consequence is worth stating plainly. Any experiment needing more than about
four and a half minutes of one continuous mission is not doable on this build,
chained or not, and that includes clearing sixteen marked fighters at two kills
per five minutes. The freeze is therefore now the highest-value target in its own
right, since fixing it would unblock the arrival question, the phase-advance
question and the OB series together. It is also a long-standing known defect
rather than anything this work introduced.

docs/re/BACKLOG.md

@@ -670,6 +670,19 @@ search cannot find a *schedule*.
   no more kills. ❔ **The earlier 4→8→12 rise is NOT reproduced** — both readings
   were HUD-confirmed, so the rise is not a stable property of the first five
   minutes; recorded as unreproduced rather than explained away.
+* ✅🔴 **(2026-08-25) THE MISSION BLACK-SCREENS AT ~4.5 MIN — that is what ends
+  every run.** Two-segment OB watch: segment 1 clean (**0/50 stalled**, OB steady
+  at 4 for 250 s); segment 2 on the same live emulator got **`NOT IN A MISSION`**.
+  Player never died (**hull 1500 throughout**), pilot log stops at **t=267 s** with
+  byte-identical lines, screen now **entirely black** (`mean=(0,0,0)`). This is the
+  known pre-existing mission-end freeze, caught in the act.
+  🔴 **Corrects "chained attaches extend the window"** — the emulator surviving is
+  not the *mission* surviving; ~4.5 min is a hard per-mission bound and chaining
+  does not cross it. ⇒ **Anything needing >4.5 min of one mission is not doable on
+  this build**, including clearing 16 marked fighters at ~2 kills/5 min. The
+  freeze is now the highest-value target: fixing it unblocks arrivals, phase
+  advance and the OB series at once. ❔ The 4→8→12 OB rise is now unreproduced in
+  **3 of 4** runs.
 * ~~🚧 BLOCKER: t=210/240 unreachable in one turn~~ — **superseded, see above**;
   it rested on an untested assumption that a turn is one shell call. 595 s shell cap − ~220 s boot (a ~190 s title movie that cannot be
   tapped through) − ~25 s startup = **~350 s observation ≈ 193 game-seconds**.