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**;