backlog: n settled as a unit count; in-table roster is the key-resolution rule

docs/re/BACKLOG.md

@@ -900,8 +900,31 @@ the route-name kind letters `F/S/A/M/B`, what activates a sub-objective, and
 durations, spawn triggers and arrival positions are not in `UnitGroup`. The
 stage record names two untouched candidates: `Formation_*.tbl` (formation
 geometry, possibly its timing) and `EnumSquadron_Test.tbl`. Also still open: the
-4-byte record key and the member field `n`. ~~the missing S17–S23 stage
-records~~ — **SETTLED 2026-08-25, and half the premise was wrong.**
+4-byte record key. ~~the member field `n`~~ — **SETTLED 2026-08-25, see below.**
+~~the missing S17–S23 stage records~~ — **SETTLED 2026-08-25, and half the
+premise was wrong.**
+* ✅ **`n` is the number of units the member tuple instantiates**, filling slots
+  of the squadron's formation. `FormationSet_S<NN>.tbl` records are **slot
+  lists** — `1 + 8·FrameCount` fields, exactly (4→33, 14→113, 30→241, 32→257).
+  Resolving every squadron's `FormationID` and comparing: **`sum(n) ≤ FrameCount`
+  holds 1159/1160 across all 28 stages, 0 unresolved, 539 filling the formation
+  exactly.** The lone violation is a debug leftover (S20, `AI_Test` /
+  `MessageSet_test`, `Formation_1_only` with `n=2`) and is recorded, not swept
+  up. The old "`n` is not the `_NN` suffix of `FormationID`" was right but drew
+  the wrong conclusion — **the suffix IS `FrameCount`**, so `n=9` against `_30`
+  just means 9 units in 9 of 30 slots.
+* ✅ **`FormationID` resolves by an in-table roster, not by hashing** — 0/16
+  resolve via `name_hash`; `FormationSet_S02.tbl` has 17 records for 16
+  formations and the extra one carries no `FrameCount`, its fields being
+  `(tag, name, "")` with the **tags equal to the record keys**. Same convention
+  as `Enumerate_Squadrons`. **Second sighting — treat it as the rule for the next
+  table.**
+* 🟡 **Does NOT close the 387-vs-~300 gap** in `roster-to-craft-link.md`. Σ`n`
+  over Stage 02 is 387 vs 296–300 live craft, but that was measured mid-mission
+  after kills and squadrons deploy across phases, so they are not comparable as
+  they stand. The earlier rejection of `n` assumed everything deploys at once —
+  **still untested**. The record-key derivation also stays ❔ (the tag is not
+  `name_hash`; a second hash function is unidentified).
 * ✅ **S18–S23 stage records were never missing.** `stagetbl.py Stage_S18` returns
   a full six-record definition and always would have; it was never run. They omit
   the literal `Stage_S<NN>` (no per-stage `.xpr`; `AIParams`/weapons/strings/