re: find the roster-to-craft link — a pointer at roster_base + 0x08

The previous iteration was right that neither structure points at the other's
base, and wrong to stop there. Craft point eight bytes into a roster record.

Resolving the 5101 "pointers into the roster range" by distance to the nearest
roster base gives a distribution that is neither flat nor diffuse: +0x08 appears
exactly 300 times, matching the 300 live craft, while every other delta appears
at most twice and 4780 of 5104 land more than 0x4000 from any base.

A count matching a count is the coincidence that has already misled this corpus
three times, so the link was tested on something a coincidence cannot survive.
Each side's unit type is resolved by a different chain -- the craft's from its
definition pointer at +0x130, the record's from its +0x04 name chain -- and they
must agree. They do, on all 300, with zero disagreements, and the fan-out
histogram is [(1, 300)]: every craft has exactly one such pointer, none has zero
or two.

The fan-in is the useful half. Only 41 of the 116 roster records are referenced
at all; the other 75 have no craft. Craft per referenced record is discrete:
24 records with 2, one with 4, four with 8, and twelve with 18 -- summing to
exactly 300. The twelve holding 18 are all e007 Turret.

This is the observable four iterations have been hunting. A member with zero
craft is not deployed; a member's craft count is its live strength; so an
arrival is craft appearing for a record that had none and a kill is that count
falling. Both are attributable to a named squadron, because the record is a
UnitGroup member and UnitGroup names the squadron that Route_S02.tbl ties to a
phase and an arrival time. The chain from a memory observation to a static route
entry is complete.

Not claimed: that the 75 undeployed members are waiting on phases 2 and 3. That
is a plausible reading, but the run only shows they have no craft.

docs/re/BACKLOG.md

@@ -339,9 +339,16 @@ search cannot find a *schedule*.
   `0xbdb2fd80`–`0xbdcd1d80`). Craft count varies run to run (296/298/300), so it
   must only be compared WITHIN a run. ❔ **Still open: the expansion rule.** Four
   candidates now dead — `Count`, `n`, formation slots, head pointers.
-  **Next test:** for the 5101 craft words pointing into the roster VA *range*,
-  plot the distance to the nearest roster-record base; a spike at one delta means
-  a link at `base+X`, a flat distribution kills the thread.
+  ✅✅ **SOLVED (2026-08-24): the link is a pointer at `roster_base + 0x08`.**
+  The delta histogram spiked at `+0x08` with exactly 300 hits for 300 craft.
+  Verified on something a coincidence cannot survive — each side's unit type
+  resolved by a *different* chain (craft via def pointer `+0x130`, record via
+  `+0x04` name chain) — **agreeing 300/300, 0 disagreements**, fan-out `[(1,300)]`.
+  Fan-in: only **41 of 116** records have craft (2×24, 4×1, 8×4, 18×12 = 300).
+  ⇒ **an arrival is craft appearing for a record that had none; a kill is that
+  count decreasing — both attributable to a named squadron**, hence to a route.
+  **Next:** watch PER-RECORD craft counts over a mission (not the global total);
+  that is the kill-vs-no-kill test with squadron resolution.
 * 🟡 **COMPETING MODEL (user, 2026-08-24): waves are event-gated, not
   clock-driven** — released by kills/objectives rather than at a fixed time, with
   the route's start time being a post-trigger delay. Fits the evidence better: