re: blocker removed — chained attaches extend the observation window

The previous iteration declared route entries t=210 and t=240 unreachable
because a shell call is capped at 595 s. That was wrong, and it rested on an
assumption I never checked: launch_mission.sh leaves the emulator running and it
survives between Bash calls within a turn. Verified directly -- 611 s elapsed
and still running after the launching call had returned.

attach_session.sh attaches a pilot and probe to an already-running mission, and
attaches chain, so the window is bounded by the turn rather than by one call.

On one continuous mission: 300 s of clean observation followed by an attach that
ran 135 s before freezing, giving 435 s of cumulative verified-live wall-clock.
The craft population fell from 300 to 258, so 42 were destroyed, and deployed
fell 41 to 38. Zero confirmed arrivals throughout -- the longest verified-live
observation so far. That covers the first four phase-1 route entries, t=90, 120,
170 and 210; t=240 needs 436 s and was missed by a second.

The coverage claim is qualified rather than asserted. The wall-to-game
conversion uses 55 %, from a 16.5/s frame rate against an assumed 30 Hz tick,
but the witness has measured 8, 11, 11, 21 and 24 per second across runs. At the
low end the factor is 0.27 and the same 435 s covers only about 117
game-seconds, reaching t=90 alone. So what is established is that nothing
arrived in 435 s of verified-live phase-1 flight with 42 kills; how many
scheduled arrival times that spans depends on a tick rate that is not yet
pinned, and pinning it is what would make the result sharp.

Also refuted: SYLPH_HZ=3, a lower pilot poll rate, produced the lowest
calibrated frame rate of any run at 8/s while landing the most kills at 26. The
pilot's polling is not the throttle and lowering it does not buy game time.

docs/re/BACKLOG.md

@@ -461,8 +461,20 @@ search cannot find a *schedule*.
   clean past 200 s. A large probability improvement, **not a fix**. Practical
   rule: run, check the witness, discard frozen runs (**3 clean of 5** now: clean
   210/240/300, frozen 60/90).
-* 🚧 **BLOCKER (2026-08-24): route entries t=210 and t=240 are UNREACHABLE in one
-  turn.** 595 s shell cap − ~220 s boot (a ~190 s title movie that cannot be
+* ✅ **BLOCKER REMOVED (2026-08-24): the emulator survives BETWEEN Bash calls in
+  a turn** (checked: 611 s elapsed, still running after the launching call
+  returned), so observation is not capped by one call.
+  `tools/re-capture/attach_session.sh` attaches pilot+probe to a live mission and
+  attaches CHAIN. Cumulative **435 s verified-live on one mission** (300 s clean +
+  135 s of an attach before it froze), craft **300→258** (42 destroyed),
+  **0 confirmed arrivals** — covering route entries t=90/120/170/**210**; t=240
+  missed by one second. 🟡 Coverage assumes the 55 % wall→game factor; the witness
+  has measured 8–24/s across runs, and at the low end the same window covers only
+  ~117 game-s (t=90 only). **Pinning the tick rate would make this sharp.**
+  🔴 `SYLPH_HZ=3` refuted as a lever: it gave the LOWEST frame rate (8/s) with the
+  most kills, so pilot polling is not the throttle.
+* ~~🚧 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**.
   t=90 needs 164 s wall ✅, t=120 → 218 s ✅, t=170 → 309 s ✅ (only on a
   non-frozen run), **t=210 → 382 s ❌, t=240 → 436 s ❌**. No number of runs fixes

docs/re/mission-arrival-watch.md

@@ -434,3 +434,63 @@ frozen), lower than the 3-of-4 quoted last iteration.
 **0 confirmed arrivals over 300 s of verified-live flight (~165 game-seconds)**,
 covering the t = 90 and t = 120 route entries. That is unchanged, and it is the
 strongest statement this harness can currently support.
+
+---
+
+# ✅ BLOCKER REMOVED: the emulator survives between calls (2026-08-24)
+
+The previous entry declared t = 210 and t = 240 unreachable because a shell call
+is capped at 595 s. **That was wrong, and it rested on an assumption I never
+tested:** `launch_mission.sh` leaves the emulator running, and it survives
+*between* Bash calls within a turn — checked directly, 611 s elapsed and still
+running after the launching call had returned.
+
+So observation is not capped by one call. `tools/re-capture/attach_session.sh`
+attaches a pilot and probe to an already-running mission, and attaches can be
+chained.
+
+## The result on one continuous mission
+
+| segment | window | stalls |
+|---|---|---|
+| initial run | 300 s | none |
+| attach | 540 s, first stall at t = 135 s | frozen after |
+
+**Cumulative verified-live: 435 s of wall-clock**, during which the craft
+population fell **300 → 258** (42 destroyed) and `deployed` fell 41 → 38.
+
+```
+TOTAL candidate-up=0 down=8 CONFIRMED arrivals=0
+```
+
+**0 confirmed arrivals**, across the longest verified-live observation yet.
+
+| route entry | wall needed | covered? |
+|---|---|---|
+| t = 90 | 164 s | ✅ |
+| t = 120 | 218 s | ✅ |
+| t = 170 | 309 s | ✅ |
+| **t = 210** | **382 s** | ✅ |
+| t = 240 | 436 s | ✗ (one second short) |
+
+Four of five phase-1 arrival times passed with nothing arriving while 42 craft
+were destroyed.
+
+## 🟡 The coverage claim is sensitive to an assumption
+
+The wall→game conversion uses 55 %, from a ~16.5 /s frame rate against an assumed
+30 Hz tick. But the witness has measured **8, 11, 11, 21 and 24 /s** across runs —
+a 3× spread. At the low end the factor is 0.27, and the same 435 s covers only
+~117 game-seconds, which would reach **t = 90 only**.
+
+So the honest statement is: **nothing arrived in 435 s of verified-live Stage 02
+phase-1 flight with 42 kills**, which covers the first four route entries *if*
+the game runs at ~55 % of real-time and only the first *if* it runs at the
+slowest rate observed. Pinning the tick rate is now the thing that would make
+this result sharp.
+
+## 🔴 Refuted: the pilot's poll rate is not what limits frame rate
+
+`SYLPH_HZ=3` (down from 8) produced the **lowest** calibrated rate of any run,
+8 /s, alongside the most kills (26). So the pilot's polling is not the throttle,
+and lowering it is not a way to buy game time. n = 1.