re: EnumUnit_S<NN> is the stage's LOAD MANIFEST; all 9 never-deployed units named

Joining each stage's own EnumerateUnit table to its own EnumerateSquadron table
is far sharper than the global partition: declared == deployed EXACTLY in 20 of
22 stages. S16 declares 4 it never deploys; S14 deploys 13 it never declares.
Every per-stage deployed-but-undeclared count is 0 except S14's 13, and that 13
is the entire disc-wide total - so the exception is one stage, not a scattering.

S16 explains what the table is. It declares 6 and deploys 2, and two of the six
are UN_e901_ADAN_Boss and UN_e910_core_ADAN_GeneratorCore - exactly the units
stage16-boss shows are brought in by their own loader chain (sub_82315AE8),
not by the squadron roster. So EnumUnit_S<NN> is the stage's load manifest, not
a mirror of the roster: a unit that code spawns is declared but never deployed.

That also closes the 9 declared-but-never-deployed units by name: the S16
code-spawned pair above, Test_ADAN_PrometheusDriver_InsideP2_01, and six
Ship_Test* placeholders.

S14 remains the one unexplained cell, and it is not a missing table:
EnumUnit_S14.tbl exists and declares six names, one of which is
UN_mn040_Asteroid_Big. S14 therefore declares an asteroid but not the 13
Asteroid_cmesh entities it deploys, which refutes "asteroids are exempt from the
manifest". Whatever the cause, it is specific to the collision-mesh entities.

All fifteen artefacts byte-identical.

docs/re/structures/unit-group-table.md

@@ -264,3 +264,42 @@ to the missing declarations — **a coincidence worth recording, not a cause.**
 
 The remaining cells are small and benign: 9 declared-but-never-deployed units,
 and one datasheet id, `Ship_`, that is neither.
+
+### ✅ Sharper, per stage: `EnumUnit_S<NN>` **is** the deployed set — 20 of 22 exactly
+
+The partition above was global, which understated the result. Joining each
+stage's own `EnumerateUnit` table to its own `EnumerateSquadron` table gives a
+much tighter statement:
+
+| | stages |
+|---|---|
+| `declared == deployed`, **exactly** | **20** |
+| declares 4 it never deploys | S16 |
+| deploys 13 it never declares | S14 |
+
+Per stage the counts are equal and the undeclared count is 0 — S01 13/13,
+S02 14/14, S03 15/15, S04 23/23, S05 13/13, S06 19/19, S07 17/17, S08 23/23,
+S09 21/21, S10 3/3, S11 10/10, S12 15/15, S13 18/18, S15 18/18, S24 11/11,
+S25 15/15, S26 15/15, S27 16/16, S28 9/9, S29 18/18. **Every per-stage
+deployed-but-undeclared count is 0 except S14's, and the 13 there are the whole
+disc-wide total** — so the global "13" is one stage's, not a scattering.
+
+🔑 **S16 explains what the table actually is.** It declares **6** and deploys
+**2**. Its six are `UN_e009_ADAN_Phantom`, `UN_f002_TCAF_DeltaSaber_W`,
+`…_W_Player`, `Test_ADAN_PrometheusDriver_InsideP2_01`, **`UN_e901_ADAN_Boss`**
+and **`UN_e910_core_ADAN_GeneratorCore`** — and the last two are exactly the
+units [stage16-boss](stage16-boss.md) shows are brought in by their own loader
+chain (`sub_82315AE8`), not by the squadron roster. So `EnumUnit_S<NN>` is the
+stage's **load manifest**, not a mirror of the roster: a unit that code spawns is
+declared but never deployed. That also names 2 of the 9 disc-wide
+declared-but-never-deployed units; 6 more are `Ship_Test*` placeholders and the
+ninth is that Prometheus-driver test entry, so **all 9 are accounted for**.
+
+🟡 **S14 remains the one unexplained cell**, and it is not a missing table:
+`EnumUnit_S14.tbl` exists and declares six names —
+`UN_e004_ADAN_ElanPlus_N`, `UN_e006_ADAN_Vindicator_Margras`,
+`UN_f002_TCAF_DeltaSaber_W`, `…_W_Player`, `UN_f201_TCAF_Tanker`,
+**`UN_mn040_Asteroid_Big`**. Note the last: S14 *does* declare an asteroid, just
+not the 13 `Asteroid_cmesh` entities it deploys. So "asteroids are exempt from
+the manifest" is **refuted for S14 itself**; whatever the cause, it is specific
+to the collision-mesh entities.