re: probe the runtime phase state — tables are resident, phase counter is not there

Static reading had gone as far as it could: the stage record splits a mission
into Phase_1..3 and every arrival route is phase-tagged, but nothing in the data
says what ends a phase. So this took it to the oracle -- one Stage 02 flight,
160 s under the survival pilot.

Confirmed, and this is the useful half: every string the static decode predicts
is present in live guest memory -- Phase_1, Phase_2, Route_ADN101_p1F,
SUBOBJ_010, AI_ADAN_CraftSquadron_Veteran, UnitGroup_S02.tbl. The game loads
exactly the tables the stage record names, under exactly the names we resolved,
and they can be located in RAM by content. That is the first dynamic
confirmation of the whole static table layer.

Refuted: the phase state is not adjacent to those strings. The probe reported
862 changed words around the anchors, which looks like a signal until you read
the values -- each word takes its predecessor's previous value and every value
points into the same region. It is one block shifted down four bytes, a single
memmove in a pointer list, occurring once between t=66s and t=89s. Diffing
around a string anchor was the cheap thing to try and it did not work.

Also recorded: a defect in my own probe. It scraped hit addresses with
0x([0-9a-f]{8}), but gmem.py find prints both the backing-file offset and the
guest VA, so half the anchors were file offsets read as addresses. Fixed to
match the va column only. It did not change the conclusion -- the anchor that
produced the shift was a real VA -- but a negative result from one of those
junk anchors would have been worthless.

Not settled: what advances a phase. Next handles are watching Route_ADN101_p1F
fire against entity positions, or working back from the SUBOBJ_*_Mes_L1 HUD
strings; the phase state is more likely near the known mutable REMAINING OB
counter than near the tables.

docs/re/BACKLOG.md

@@ -310,7 +310,17 @@ search cannot find a *schedule*.
   and 14 manoeuvre weights per profile). 🔴 Refuted: the 8-value frame is *not*
   universal — `Formation_Fleet_01/02` use 136 and 4 values per frame.
 
-**First step (next):** find what *advances a phase* — the stage declares
+* 🔴 **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
+  dynamically that every table the static decode predicts is resident in guest
+  RAM and findable by name, which validates the whole static layer against a
+  running mission. Next handles: watch `Route_ADN101_p1F` actually fire against
+  entity positions, or work back from the `SUBOBJ_*_Mes_L1` HUD strings; the
+  phase state is more likely near the known mutable `REMAINING OB` counter at
+  `0xbdb59668` than near the tables.
+
+**Superseded first step:** find what *advances a phase* — the stage declares
 `Phase_1..3` and routes are phase-tagged, but nothing static found so far says
 what ends a phase. This is the point where the oracle should be measured rather
 than reasoned about: fly Stage 02 and watch for the phase transition. Also open: