re(units): stage select lifts the per-stage coverage limit — 21 -> 26 units

Unit definitions are instantiated per stage, so the parked "coverage grows by
visiting missions" limit was blocked on progress. With the save's stage field
solved, any story stage can be flown from a hand-edited save and snapshotted.

First harvest (a Night Ravens mission, 027 objectives, different roster):
  units with runtime values   21 -> 26
  csv rows                 1 827 -> 2 143
  defaulted-on-disc values   963 -> 1 059

New: UN_e004_ADAN_ElanPlus_N, UN_e006_ADAN_Vindicator_Margras,
UN_f002_TCAF_DeltaSaber_W, UN_f002_TCAF_DeltaSaber_W_Player (a second player craft)
and UN_mn040_Asteroid_Big (47 defaulted values, Size_Z = 2000).

Two traps recorded with the fix: launch_mission.sh presses A on the PRESELECTED
slot, which is the last-used one (03 here), so a probe in slot 01 is ignored — the
first attempt flew stage 02 again and the solver correctly found 0 new units; patch
every slot or confirm the highlighted slot by screenshot. And back up before
patching: the mid-run backup already held the probe, so slot 01 was restored from
the earlier pristine copy (md5 142b4f43…, verified byte-identical).

Token file for the solver: idxd_tokens <GP_MAIN_GAME_E.pak> Generic — 110 UN_*
records, the disc's full unit count.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NptfmpjdpNCKEez6d2xvA9

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

@@ -377,3 +377,40 @@ which the key-string extraction did not pick up.
 `+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.
+
+## Stage select makes the coverage limit go away (2026-08-13)
+
+Unit definitions are instantiated **per stage**, so this note's coverage figure
+(21 units, "grows by visiting missions") was blocked on progress. It no longer is:
+the save's stage field is solved ([savegame](savegame-format.md#-solved-52-is-the-stage-and-the-save-picks-the-mission-2026-08-13)),
+so any story stage can be flown from a hand-edited save and snapshotted.
+
+First harvest — a mission at the **Night Ravens** (027 objectives, a different
+roster entirely):
+
+| | before | after |
+|---|---|---|
+| units with runtime values | 21 | **26** |
+| rows in [`unit-runtime-fields.csv`](../captures/unit-runtime-fields.csv) | 1 827 | **2 143** |
+| defaulted-on-disc values | 963 | **1 059** |
+
+New units: `UN_e004_ADAN_ElanPlus_N`, `UN_e006_ADAN_Vindicator_Margras`,
+`UN_f002_TCAF_DeltaSaber_W`, `UN_f002_TCAF_DeltaSaber_W_Player` (a second player
+craft!) and `UN_mn040_Asteroid_Big` (47 defaulted values, `Size_Z = 2000`).
+
+**Two traps, both paid for in this run:**
+
+1. **`launch_mission.sh` does not load slot 01.** The LOAD GAME list preselects the
+   **last-used** slot — here **03** — and the script simply presses `A` on it, so a
+   probe written to slot 01 is ignored and the game flies whatever that slot holds.
+   The first "stage 14" snapshot was therefore stage 02 again, and the solver
+   correctly reported **0 new units**. Fix used: **patch every slot** (01/02/03) to
+   the target stage, or drive the list explicitly and confirm the highlighted slot
+   by screenshot before pressing `A`.
+2. **Back up before patching, not after.** The backup taken mid-run already
+   contained the probe, so "restoring" it restored the probe; the pristine copy from
+   the earlier session was what actually restored slot 01 (`142b4f43…`, verified).
+
+Regenerating the solver's token file: `idxd_tokens <GP_MAIN_GAME_E.pak> Generic`
+emits the `REC`/`F` records `unit_runtime.py` wants — **110** of them are `UN_*`,
+which is the disc's full unit count.