5ec24b8ef9
Two measurements settle the last open cell of the unit partition. The deployment side is identical. S14's asteroid-cmesh squadron records match a declaring stage's field for field - same squadron ids (GNN901, GNN902, ...) and the same Count 1 / SideID Neutral / AIID AI_Structure / FormationID Formation_1_only / DisableInterval No. Nothing about how S14 deploys them differs, and these are the same kind of record compared like for like. The definition side differs completely. Per stage, deployed / declared / Generic-with-HP / any Generic: S01 8/8/8/8, S04 10/10/10/10, S05 5/5/5/5, S08 6/6/6/6, S13 4/4/4/4 - 33/33/33 for the five - and S14 p1 9/0/0/0, S14 p2 4/0/0/0. So the 13 are not a manifest omission: they have no unit definition anywhere on the disc, not even an un-HP'd Generic row. UnitGroup_S14.tbl names entities that do not exist - 13 dangling references. That rescues the law (nothing is deployed-without-being-loaded in any working sense) and explains why the gap is exactly the cmesh class and nothing else in S14. What it predicts needs the emulator: either those collision meshes fail to appear in Stage 14 - a shipped bug - or another route supplies them. Flying S14 and checking whether the large asteroids collide distinguishes the two; no static route can. Recorded as NEEDS-HUMAN. Also recorded so the two asteroid populations are not conflated: asteroid-fields' AsteroidGroup_00N tables scatter mob_n0NN models, while these are UN_<stage>_Asteroid_cmesh_* squadron entities. S28.Phase_1 borrows S14_p2_asteroid.tbl but deploys no cmesh of its own, so the borrow does not carry the dangling references. All fifteen artefacts byte-identical.