925006d38f
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.
839 B
Executable File
839 B
Executable File