da41f95db1
Perfect diagonal. Each of stg24_01..04, stg26_01..03, stg27_01..02 and stg29_01..02 appears in Stage_S<NN>.xpr and in no other stage package. So a challenge stage's bespoke LOD/model table exists to declare the handful of scenery meshes packaged with that stage, consistent with xbg7-mesh's account of a stage .xpr as a bag of XBG7 resources. stg24_04 is a composite: 22 occurrences resolve as 1 bare + 1 _all + 20 _child. Every other stg* name occurs exactly once. rou_f004 is NOT in Stage_S28.xpr - it is in DeltaSaber_A.xpr. S28's LOD table declares the craft but the mesh ships in the player-craft package, confirming from the ISO side that _A is the f004 variant: the stage package carries scenery, the craft comes from its own file. rot_n001_break resolves too, in Tutorial.xpr and Stage_S28.xpr, matching exactly the tables that list it. The orphan tables' unique effects only partly resolve: eff_e0033 is present in Base.xpr, but eff_e0058 and eff_n0071 appear in NO .xpr on the disc. So the six abandoned LOD tables name at least two effects that were never packaged - the same "declared, never shipped" shape as S14's asteroid meshes, on a much smaller scale. Method caveats recorded in the doc: these are byte searches over .xpr files, not parsed resource-table reads. They establish presence, not an enumeration, and are acceptable only because the names are long and distinctive and the match was expanded to the full trailing token. Also grep -c counts LINES, not occurrences; the counts above come from grep -o | wc -l after that was caught. All fifteen artefacts byte-identical.