de42fbd742
FormationSet_S<NN>.tbl records are slot lists -- 1 + 8*FrameCount fields, exactly. Resolving every squadron's FormationID and comparing gives sum(n) <= FrameCount holding 1159/1160 across all 28 stages, 0 unresolved, with 539 filling the formation exactly. The single violation is a debug leftover (S20, AI_Test / MessageSet_test, Formation_1_only with n=2) and is recorded. The old 'n is not the _NN suffix of FormationID' observation 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. Also: FormationID does not hash into its table (0/16). FormationSet carries a name roster record -- no FrameCount, fields are (tag, name, '') with the tags being the record keys -- the same convention as Enumerate_Squadrons. Second occurrence of 'keys are resolved by an in-table roster, not by hashing'. Does not close the 387-vs-300 gap, and the key derivation stays open.