re: refute a direct pointer link between roster records and live craft

Fourth failed attempt to explain how 116 roster members become ~300 live craft,
recorded so it is not retried. Count (116), the member field n (387) and
formation slots (630) were rejected earlier; this rejects a head pointer.

link_probe.py scans the first 0x400 bytes of every object for an address of the
other kind. Roster record to craft base: 0 of 116. Craft to roster base: 0 of
300. Both directions empty.

The scan also measured the address spaces, which is the useful part. The two
structures live in different regions about 19 MB apart -- roster records at
0xbc372c00..0xbc9bc720, craft at 0xbdb2fd80..0xbdcd1d80 -- and the 14 unit
definitions match Stage 02's 14 distinct unit types exactly. The craft count is
not fixed: three runs at comparable mission times gave 296, 298 and 300, so the
population must be compared within a run and never across runs.

One thread is left open but explicitly not counted as evidence. Craft objects
hold 5101 words pointing somewhere into the roster VA range, which sounds like a
lot until you notice that range spans 6.5 MB and holds many allocations besides
the 116 records. The test that would settle it is the distance from each such
pointer to the nearest roster-record base: a spike at a single delta means a
link at base+X, a flat distribution kills the thread. Not run yet.

The association may not be a pointer at all -- an index, a hash, or a third
object such as a squadron instance would all look like this. Since an arrival is
already known to be a state change rather than an allocation, finding that
mediating structure matters more than finding a flag: it is what would let an
observed change be attributed to a named squadron and hence to a route.

docs/re/roster-to-craft-link.md

@@ -0,0 +1,64 @@
+# The 116 roster records and the ~300 live craft are not directly linked
+
+Status: 🔴 a direct pointer link is refuted in both directions; ✅ the two
+structures are in distinct heap regions; ❔ how a roster member expands into
+craft is still unknown.
+
+Four attempts have now failed to explain how 116 roster members become ~300
+live craft — `Count` (116), the member field `n` (387), formation slot count
+(630, rejected), and now a pointer link. This records the fourth so it is not
+retried.
+
+## The two structures
+
+| | vtable / locator | count | VA range (measured) |
+|---|---|---|---|
+| roster records | `0x820AF030` | **116** | `0xbc372c00 … 0xbc9bc720` |
+| live craft | def-pointer site − `0x130` | **296–300** | `0xbdb2fd80 … 0xbdcd1d80` |
+| unit definitions | `0x820AF844` | 14 | — |
+
+They are in **different regions**, ~19 MB apart, and neither range overlaps the
+other. The 14 definitions match Stage 02's 14 distinct unit types exactly.
+
+The craft count is not fixed: three runs at comparable mission times gave 296,
+298 and 300. That is expected now that kills are confirmed, but it means the
+craft population must be compared *within* a run, never across runs.
+
+## 🔴 Refuted: neither structure points at the other
+
+`tools/re-capture/link_probe.py` scans the first `0x400` bytes of every object
+for a word equal to a known address of the other kind.
+
+* roster record → craft base: **0 of 116** records hold one.
+* craft → roster record base: **0 of 300** craft hold one.
+
+Both directions are empty, so whatever associates a member with its craft is not
+a pointer at the head of either object.
+
+## ❔ The one loose thread, and why it is not evidence yet
+
+The same scan counted pointers into the *ranges* rather than at exact bases:
+
+* roster words pointing anywhere into the entity heap: **181**, of which only
+  **2** land within `0x400` of a known craft base;
+* craft words pointing anywhere into the roster VA range: **5101**.
+
+5101 looks like a lot, but the roster range spans 6.5 MB and certainly holds
+many allocations besides the 116 records, so pointers "into the range" may have
+nothing to do with roster records at all. **This is deliberately not being read
+as a link.**
+
+The test that would make it evidence: for each of those 5101 pointers, compute
+the distance to the nearest roster-record base below it. If the association is
+"craft points at `roster_base + X`" for some fixed `X`, that distribution spikes
+at a single delta. If it is flat, the pointers are unrelated allocations and the
+thread is dead.
+
+## What this means for the wave question
+
+The association may not be a pointer at all — it could be an index, a hash, or
+mediated by a third object (a squadron or formation instance) that neither side
+names directly. Since an arrival is already known to be a *state change* rather
+than an allocation ([mission-liveness-probe.md](mission-liveness-probe.md)),
+finding the mediating structure matters more than finding a flag: it is what
+would let a change be attributed to a named squadron and therefore to a route.