re: cross-validate the code-derived layout against the earlier RAM-binding solver

Two independent derivations of the unit definition layout -- the earlier
disc-value-to-RAM-word solver and this session's extraction from the loader's own
key strings -- agree on 25 of 25 shared offsets, 0 disagreements. The code-derived
table covers 159 fields against 27 confirmed, while the earlier one uniquely holds
ScorePoint (+0x08c) and MassScore (+0x094).

Also flags a tentative entry as an artefact: Slalom_CutoffRatio at +0x00c records
2.8026e-45 / 1.4013e-45, which are the denormal readings of the integers 2 and 1 --
the same trap that produced a false YawDragFactor hit while building the new map.
INDEX updated.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/re/structures/unit-struct-runtime.md

@@ -353,3 +353,27 @@ are the same numbers their already-captured base variants gave, so it would
 re-measure rather than test. A real test needs a stage with unfamiliar classes,
 i.e. story progress — which is now the *only* thing story progress is needed for
 here.
+
+## Cross-validated against the loader itself (2026-08-13)
+
+This layout was solved by binding disc values to RAM words. It has now been
+derived a second time, independently, **from the game's own code**: the loader
+`sub_82341A20` builds every key as `addi r4, r30, -N` (`r30 = 0x82088f94`), so the
+field *name* for each store is a string in the executable, and pairing each key
+with the first store after its accessor call gives the offset without any value
+matching. See [`live-unit-definitions.md`](../live-unit-definitions.md).
+
+**The two agree completely where they overlap: 25 shared offsets, 25 agree, 0
+disagree.** Each also covers what the other misses — the code-derived table has
+**159 fields** (vs 27 confirmed here) and is checked in as
+`crates/sylpheed-formats/data/unit_definition_layout.txt` with
+`sylpheed_formats::unit_layout` and a no-emulator regression test; this table
+still uniquely holds **`ScorePoint` (`+0x08c`)** and **`MassScore` (`+0x094`)**,
+which the key-string extraction did not pick up.
+
+⚠️ **One tentative entry here is an artefact and should not be trusted.**
+`Slalom_CutoffRatio` at `+0x00c` is recorded with values like `2.8026e-45` and
+`1.4013e-45` — those are the **denormal float readings of the integers 2 and 1**.
+`+0x00c` is below the first field the loader ever names (`+0x018`), and the same
+trap produced a false `YawDragFactor → +0x0c` hit when the code-derived map was
+being built. It is an int-typed word, not a ratio.