re: the 42 anomaly is Stage 01, and the route times are probably frames

The rescan-until-baseline retry settled the anomaly: five rescans over 50 s
stuck at 42, so not a load race. Inspecting the live mission rather than
guessing, the records include UN_S01_Asteroid_cmesh_* and UnitGroup_S01.tbl is
resident while UnitGroup_S02.tbl is not. The launch sometimes loads Stage 01
instead of Stage 02, and the discard rule caught every such run, which is why
none of them contaminated a result.

That accident supplies a test previously recorded as blocked. The roster
identity needed checking against a different stage, and no second save exists.
Stage 01 provides one: static 42 members and 13 distinct units against live 42
roster records and 13 definitions, with composition matching 20/20, 6/6, 5/5 and
2/2. One record per roster member now holds on two independent stages with
completely different rosters.

Stage 01's timetable also bears on the unit question, which has been open since
the schedule was found. Its phase 2 has entries at t=1500, 1800 and 2100. As
seconds that is 25 to 35 minutes into a single phase, with three arrivals spread
across the last ten minutes of it, which is not a plausible mission. At 30 Hz
they are 50, 60 and 70 seconds, which is exactly the shape of a paced phase.

If the unit is frames, Stage 02's phase-1 entries at 90, 120, 170, 210 and 240
are 3 to 8 seconds, every one of them before the probe's first sample, which
lands about 25 s after flight is detected. That would explain every null result
in this line of work at a stroke, and it fits what the probe has always seen:
deployed already at 41 by t=0 and never changing.

Kept at 🟡 -- it is an inference from the implausibility of one reading rather
than a measurement -- but it is now the leading explanation, ahead of
event-gating. The test is to sample at flight+2 s and compare with flight+30 s,
which needs the probe's enumeration and calibration reordered after a first
cheap sample rather than any new decoding.

docs/re/BACKLOG.md

@@ -471,6 +471,19 @@ search cannot find a *schedule*.
   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.**
+* ✅🟡 **(2026-08-24) The 42-anomaly is STAGE 01, and it hands us two results.**
+  Rescans stuck at 42 (not a load race); live RAM holds `UN_S01_Asteroid_cmesh_*`
+  and `UnitGroup_S01.tbl` with S02 absent — **the launch sometimes loads Stage 01**
+  (the discard rule caught every such run). ✅ That supplies the refutation test
+  recorded as *blocked* for lack of a second stage: S01 static **42 members / 13
+  units** vs live **42 records / 13 definitions**, composition 20/20, 6/6, 5/5,
+  2/2 — **one record per member now holds on two independent stages.**
+  🟡 **Route times are almost certainly FRAMES**: S01 phase 2 has t=1500/1800/2100,
+  which as seconds is 25–35 min into one phase (implausible) but at 30 Hz is
+  50/60/70 s. ⇒ S02's t=90…240 would be **3–8 seconds**, all before the probe's
+  first sample (~25 s in) — explaining every null result, and consistent with
+  `deployed=41` already at t=0. **Test: sample at flight+2 s vs flight+30 s** —
+  a reordering of the probe, not new decoding.
   🔴 `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**;

docs/re/mission-arrival-watch.md

@@ -494,3 +494,69 @@ this result sharp.
 `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.
+
+---
+
+# 🟡 The route times are almost certainly FRAMES — and the "42 anomaly" was Stage 01
+
+## ✅ The 42-record anomaly is solved: it is a different stage
+
+The rescan-until-baseline retry settled it — five rescans over 50 s, stuck at 42,
+so not a load race. Inspecting the live mission instead of guessing:
+
+* records include `UN_S01_Asteroid_cmesh_01a/01b/02a/…` — Stage 01 asteroids;
+* `UnitGroup_S01.tbl` is resident in guest RAM, `UnitGroup_S02.tbl` is **not**.
+
+**The launch sometimes loads Stage 01 instead of Stage 02.** The discard rule
+caught every one of those runs, which is why they never contaminated a result.
+
+## ✅ And that supplied the missing refutation test, for free
+
+`mission-liveness-probe.md` recorded the roster identity as blocked: the obvious
+check — a *different* stage's record count against its member sum — needed a save
+we do not have. Stage 01 loading by accident provides it:
+
+| | static (disc) | live (RAM) |
+|---|---|---|
+| members / roster records | **42** | **42** |
+| distinct unit types / definitions | **13** | **13** |
+| `UN_e007_ADAN_Turret` | 20 | 20 |
+| `UN_f001_TCAF_DeltaSaber_T` | 6 | 6 |
+| `UN_e010_ADAN_Attacker_S` | 5 | 5 |
+| `UN_e106_ADAN_Destroyer` | 2 | 2 |
+
+One record per roster member now holds on **two independent stages** with
+completely different rosters.
+
+## 🟡 Stage 01's timetable says the unit is frames, not seconds
+
+```
+Stage 01 phase 1:  t=0:15, t=40:3, t=70:2, t=80:1, t=110:1, t=140:1
+Stage 01 phase 2:  t=0:17, t=1500:1, t=1800:3, t=2100:4
+```
+
+**t = 2100 as seconds is 35 minutes into a single phase**, and 1500/1800/2100
+would be three arrivals spread over the last ten minutes of it. That is not a
+plausible mission. At 30 Hz they are **50, 60 and 70 seconds**, which is exactly
+the shape of a paced phase.
+
+If the unit is frames at 30 Hz, then Stage 02's phase-1 entries at
+t = 90/120/170/210/240 are **3, 4, 5.7, 7 and 8 seconds** — every one of them
+before the probe's first sample, which lands ~25 s after flight is detected.
+
+**That would explain every null result in this file at a stroke**, and it is
+consistent with what the probe has always seen: `deployed = 41` already at t = 0
+and never changing.
+
+Kept at 🟡: it is an inference from the implausibility of one reading, not a
+direct measurement. But it is now the leading explanation, ahead of event-gating.
+
+## The test that would settle it
+
+Sample **within the first seconds of flight**, before startup costs, and compare
+`deployed` at flight+2 s against flight+30 s. Under the frames reading the count
+climbs during those seconds and is finished before the current probe ever looks;
+under any seconds reading it is flat there and climbs later.
+
+That requires the probe's ~25 s of enumeration and calibration to happen *after*
+a first cheap sample, which is a reordering rather than new decoding.