re: the mission clock is running — refute the stopped-clock explanation

The prime suspect from the previous iteration was that the phase scheduler
simply is not running, which would have made every arrival result meaningless.
It is refuted.

timer_probe.py takes three equally-spaced snapshots of the 32 MB game heap with
no pilot -- exactly the condition where nothing had been observed to change --
and keeps words whose two successive deltas are both positive and agree within
12 %, so linear rather than merely noisy. 286 words qualify, with a large
cluster advancing in lockstep at 16.5 per second.

That rate is not a coincidence: the existing performance notes put Canary
playback on this box at roughly 14-19 fps, and the dominant counter sits inside
that band, so these read as per-frame counters.

Which gives a mundane explanation for six arrival-free runs. If the scheduler is
frame-driven and the title targets 30 Hz, game time advances at about 55 % of
wall-clock here, so the 168, 190 and 240 second runs covered roughly 92, 105 and
132 seconds of game time. Route_S02 schedules phase-1 arrivals at 90, 120, 170,
210 and 240, so the longest run passed the first two and came nowhere near the
last three. No model has to be wrong for the observations to be empty.

Kept at 🟡, not promoted: two links are assumed rather than measured -- that
these counters are frame counters, and that the game's tick is 30 Hz. The values
also do not fit a naive frame count, since the cluster read 14193 about 255 s
after emulator start, which matches neither 16.5 nor 30 per second, so their
origin is genuinely unknown and no counter is claimed to be the mission clock.

Next is one long run, ~350 s of probe, watching for a 0 -> n transition near
t = 163 s and 218 s wall, where the t = 90 and t = 120 route entries land at 55 %
speed. If 350 s still yields nothing, the frame-rate explanation is itself
refuted and the event-gated model returns as the front-runner. The ~210 s title
movie at boot is the binding constraint on how much game time one turn can
observe.

docs/re/BACKLOG.md

@@ -360,10 +360,17 @@ search cannot find a *schedule*.
   2×24/4×1/8×4/18×12). ✅ **Losses require the player**: an unpiloted run held at
   exactly 300 craft for 240 s / 22 samples, vs 16–20 losses in each piloted run —
   so NPC crossfire destroys nothing on its own. 🔴 **Zero `0→n` arrivals in either
-  condition**, ~15 min cumulative. ❔ **Prime suspect: the phase clock may not be
-  advancing at all** — never checked. **Next: find the mission timer** (HUD digits
-  or a fixed-rate counter); if it is stopped, every arrival result so far is
-  measuring a stopped clock.
+  condition**, ~15 min cumulative. 🔴 **Prime suspect REFUTED (2026-08-24):
+  the clock is running** — [`mission-clock-advances.md`](mission-clock-advances.md).
+  With no pilot, 286 heap words advance linearly, a large cluster in lockstep at
+  **16.5/s**, which is the emulator's known ~14–19 fps. 🟡 New leading
+  explanation: **the runs were far too short in GAME time** — at ~55% of
+  wall-clock, the longest 240 s run reached only t≈132, past the t=90/120 route
+  entries but nowhere near t=170/210/240. **Next: one long run** (~350 s probe)
+  watching for `0→n` near t≈163 s and 218 s wall. If still nothing, the
+  frame-rate explanation is refuted and event-gating returns as front-runner.
+  ⚠️ The ~210 s title movie at boot is the binding constraint on observable game
+  time per turn.
   Earlier framing:
   [`mission-per-record-strength.md`](mission-per-record-strength.md) — one run
   gives 116 records/300 craft, the next 42/170, same disc, save and script. Save

docs/re/mission-clock-advances.md

@@ -0,0 +1,80 @@
+# The mission clock is running — the runs were too short in *game* time
+
+Status: 🔴 "the phase clock is stopped" is refuted; ✅ something advances
+linearly at ~16.5–17 /s; 🟡 the leading explanation for six arrival-free runs is
+now that they covered far less game time than wall-clock time; ❔ the counters'
+exact identity is not established.
+
+## 🔴 Refuted: the clock is not stopped
+
+[mission-arrival-watch.md](mission-arrival-watch.md) named this the prime
+suspect — every "no arrival" result was equally consistent with a scheduler that
+simply was not running, and nothing had checked.
+
+`tools/re-capture/timer_probe.py` takes three equally-spaced snapshots of the
+game heap (`0xBC000000–0xBE000000`, 32 MB) **with no pilot**, i.e. in exactly the
+condition where nothing was observed to change, and looks for words whose two
+successive deltas are both positive and agree within 12 % — linear, not merely
+noisy.
+
+```
+actual gaps: 20.1s, 20.5s   region 32.0 MB
+linearly-increasing words: 286
+rate histogram (/s): [(17, 111), (27, 27), (44, 19), (1, 10), (47, 10), ...]
+
+va 0xbc4428a8   14193 -> 14519 -> 14863   16.5/s
+va 0xbc65c948   14195 -> 14521 -> 14865   16.5/s
+va 0xbc668648   14193 -> 14519 -> 14863   16.5/s      (and many more identical)
+```
+
+286 counters advance steadily, a large cluster of them in lockstep at **16.5 /s**.
+The guest is running. The stopped-clock explanation is dead.
+
+## 🟡 What this probably means: the runs were far too short
+
+**16.5 /s is the emulator's frame rate, not a coincidence.** The existing
+performance work records Canary playback on this box at roughly **14–19 fps**,
+and the dominant counter rate sits squarely inside that band. These read as
+per-frame counters.
+
+If the mission's scheduler is frame-driven and the title targets 30 fps, then
+game time advances at about **55 % of wall-clock** here. Every run so far:
+
+| run window (wall) | approximate game time |
+|---|---|
+| 168 s | ~92 s |
+| 190 s | ~105 s |
+| 240 s | ~132 s |
+
+`Route_S02.tbl` schedules phase-1 arrivals at t = 90, 120, 170, 210, 240. So the
+longest run reached roughly t = 132 of game time — **past the first two
+scheduled arrivals but nowhere near the last three**, and the shorter runs barely
+reached the first. That is a mundane and sufficient explanation for a string of
+empty results, and it does not require the event-gated model to be wrong or the
+timetable to be in frames.
+
+It is 🟡 rather than ✅ because two links in it are assumed, not measured: that
+these counters are frame counters, and that the game's own tick is 30 Hz.
+
+## ❔ What the counters are is not established
+
+The value does not fit a naive frame count. The dominant cluster read 14193 at
+the first snapshot, roughly 255 s of wall-clock after emulator start — 14193
+frames at 16.5 /s would be ~860 s, and at 30 /s ~473 s. Neither matches, so
+these are not simply "frames since boot". They advance in lockstep and at frame
+rate, but their origin is unknown and no claim is made about which one, if any,
+is *the* mission clock.
+
+## Next: one long run
+
+The decisive test is now cheap in design and expensive only in wall-clock: run
+the arrival watch for the longest window the turn allows (~350 s of probe after a
+~210 s boot) and check for `0 → n` around **t ≈ 163 s and 218 s wall**, which is
+where the t = 90 and t = 120 route entries land at 55 % speed. If arrivals appear
+there, the timetable is in game-seconds and the clock model is confirmed. If 350 s
+still yields nothing, the frame-rate explanation is itself refuted and the
+event-gated model returns as the front-runner.
+
+The boot's ~210 s title movie is the binding constraint on how much game time a
+single turn can observe, and is worth attacking separately if this becomes the
+limiting factor.