re: diff inside the 116 entity records — no arrival flag found, two probe defects

Since the record count is flat, an arrival would have to flip a field inside a
record. This diffed all 116 records every 5 s for 170 s of Stage 02 flight.

The prediction under test -- groups of 3, 3, 3, 2, 1 records changing state at
t = 90, 120, 170, 210, 240 s -- did not appear. Changes are spread evenly across
ticks with no cluster at any predicted time and no field that transitions once
for exactly three records. Three explanations survive and this run cannot
separate them: the timetable's t is not seconds (at 30 Hz the whole phase-1
schedule finishes inside 8 s, before the first sample); arrival is not marked in
these records; or the mission was not in phase 1.

Supporting, not conclusive: only 10 of 116 records ever changed a byte, and 106
never changed at all. Live entities would be moving, so that fits the
pre-allocated roster reading -- but Stage 02's roster is turret-heavy and a
turret does not move while alive, so "inert" and "not yet arrived" are not
distinguishable here.

Two defects in my own probe, recorded rather than quietly fixed:

  - label() resolved to '?' for all 116 records, so nothing could be tied back
    to a squadron. That association is what would have made the result
    decisive -- "the three records that changed at t=90 are ADN110, ADN111,
    ADN112" is evidence; "records 18, 32, 99" is not. unit_discover.py already
    solves this and should be reused.
  - RECLEN=0x200 was assumed, not measured. The busiest fields are the last
    eight words of the window, which is what spilling into the next object
    looks like.

Method error kept: the first attempt deferred all analysis to the end and the
turn timeout killed it with 240 s of data in memory and nothing written. The
probe now streams transitions to disk and prints a partial ranking every 60 s.
With a 219 s cold-boot title movie, an end-only report has ~300 s of budget and
one bad estimate loses the whole run.

docs/re/BACKLOG.md

@@ -320,6 +320,15 @@ search cannot find a *schedule*.
   record per member (n=1, NOT promoted; the refutation needs another stage's
   save, which we do not have — only slot 01 / Stage 02 exists).
   ❔ Still unmeasured: whether the timetable's `t` is frames or seconds.
+* 🔴 **Diffing inside the 116 records did not find the arrival flag**
+  (2026-08-24, same doc). 10 of 116 records are dynamic, 106 never change a byte
+  in 170 s — more support for the pre-allocated roster, though turret-heavy S02
+  means "inert" ≠ "not arrived". No field transitions in groups of 3 at the
+  predicted times. **Blocked on two of my own defects**: the record→unit-ID
+  label resolved to `?` for all 116 (reuse `unit_discover.py`, do not re-derive),
+  and `RECLEN=0x200` was assumed, not measured — the busiest fields sit at the
+  very end of the window, which is what spilling into the next object looks like.
+  Fix both before diffing these records again.
 * 🔴 **Probed 2026-08-24 and refuted the cheap hypothesis** — the phase state is
   NOT adjacent to the loaded table strings; see
   [`mission-phase-runtime.md`](mission-phase-runtime.md). The run did confirm