re: the in-game HUD config -- 16 records, 419 asset paths, a per-stage ResourceTable

Checked first: no docs/re file mentions ArmsStatus, RangeFinder, Radar,
Sight, Wing, NamePlate or ResourceTable.  Only HudResource had been
opened; the other fifteen records had not.

The six IDXD entries of GP_MAIN_GAME_E2D.pak: two carry the 16-record
HUD config, two the 13-record ObjectiveMarker_*/TutorialMarker_* set,
one Face (52 portrait sprites), one ResourceTable.  Between them they
name 419 distinct asset paths -- the whole flight HUD -- with new
subdirectory prefixes throughout (ArmsSt, ActvArm, RangeF, Marker,
Manuva, Map, Speed, Radar, Sight, Wing, Hitmark, Lockon, Info).

The decisive control uses the config's own exact path strings, so no
guessing is left in the loop: 419 distinct .prt/.t32/.tbl values, ZERO
resolve as a pak entry under 10 prefixes, and the four config filenames
resolve to nothing either.  The .t32 sprites certainly exist -- 574 T8aD
in that pak.  So the 2D pak is not addressed by name_hash of the name
its config uses.

This supersedes the earlier framing: the 28 'dangling' .prt names were
never a missing-asset story; they are 28 of a set where none of the 419
resolves.

ResourceTable is 58 positional fields = 29 pairs, alternating
HudResource.tbl / HudMarkerResource.tbl, identical in all six language
paks, with exactly one override at pair index 25 -- HudResource_S26.tbl.
Reading: indexed by stage number minus 1, so index 25 is S26, the one
stage with its own HUD config.  Arithmetic exact, indexing unproven, not
adopted.

New structure doc, artefact and regenerator; the other seven regenerate
byte-identical.

docs/re/structures/hud-config.md

@@ -0,0 +1,70 @@
+# ✅ The in-game HUD configuration — 16 records, and a per-stage resource table
+
+The `GP_MAIN_GAME_*2D.pak` archives carry **six IDXD entries** that are the
+in-game counterpart of `tables.pak`'s menu configs. Only `HudResource` had been
+opened ([mission-script-manifest](mission-script-manifest.md)); the other
+**fifteen** records had not. No `docs/re/` file mentions `ArmsStatus`,
+`RangeFinder`, `Radar`, `Sight`, `Wing`, `NamePlate` or `ResourceTable` —
+checked before writing this. Artefact `../data/hud-config.txt` (697 lines),
+regenerator `tools/re-capture/hud_config.py`.
+
+| entry | records |
+|---|---|
+| `0x10b9d584`, `0x4abcfc43` | **16** — `ArmsStatus`, `Map`, `ArmsItem`, `RangeFinder`, `Marker`, `Manuva`, `Number`, `HudResource`, `NamePlate`, `ActiveArm`, `Information`, `Wing`, `ArmsItemFile`, `Radar`, `Speed`, `Sight` |
+| `0x927b29f8`, `0xccb12a6b` | **13** — `ObjectiveMarker_{Acropolis,SubObjective,Guard,WayPoint,Tanker,Target}`, `TutorialMarker_{…}`, `Enumerate_ObjectiveMarkers`, `Parameters` |
+| `0x59ecbedd` | `Face` — 52 positional `pjf001_*.t32` portrait sprites |
+| `0x87fd28c0` | `ResourceTable` — 58 positional entries |
+
+Between them these name **419** distinct asset paths. That is the whole flight
+HUD: the arms panel (`ArmsStatus` 16, `ActiveArm` 13, `ArmsItemFile` 59), the
+range finder (10), the target/lock markers and their HP-gauge strips (`Marker`
+27), the manoeuvre gauge (`Manuva` 15), the radar (29), the reticle (`Sight`
+35), the wingman panel (`Wing` 23), nameplates (60), speed (9), and the digit
+strips (`Number`, `%d`-templated: `pghud_speed_num%d.t32`, `pgtimer_num%d.t32`,
+`pglockon_%d.t32`).
+
+🔑 The values carry **subdirectory prefixes** the corpus had not seen —
+`ArmsSt\`, `ActvArm\`, `RangeF\`, `Marker\`, `Manuva\`, `Map\`, `Speed\`,
+`Radar\`, `Sight\`, `Wing\`, `Hitmark\`, `Lockon\`, `Info\`.
+
+## 🧪 The whole in-game HUD is NOT name-hash addressed
+
+Taking the config's **own exact path strings** — no guessing left in the loop:
+
+> **419 distinct `.prt` / `.t32` / `.tbl` values; 0 resolve as a pak entry**
+> under 10 prefixes. The four config FILENAMES (`HudResource.tbl`,
+> `HudMarkerResource.tbl`, and their `_S26` overrides) resolve to nothing
+> either.
+
+The `.t32` sprites certainly exist — the E2D pak holds **574 T8aD** entries. So
+the 2D pak's contents are simply **not addressed by `name_hash` of the name the
+config uses**, and that closes the previous iteration's puzzle properly: the 28
+"dangling" `.prt` names were never a missing-asset story, they are 28 of a set
+where **none** of the 419 resolves.
+
+⚠️ This supersedes the framing in
+[mission-script-manifest](mission-script-manifest.md#-the-other-six-values-do-not-resolve--with-a-working-control):
+the right statement is not "these five/28 are absent" but "**the in-game asset
+namespace is not the archive namespace**".
+
+## ✅ `ResourceTable` — a per-stage HUD config table
+
+58 positional fields = **29 pairs**, alternating
+`HudResource.tbl` / `HudMarkerResource.tbl`. Exactly one pair differs — index
+**25**, which reads `HudResource_S26.tbl` / `HudMarkerResource_S26.tbl`.
+**Identical in all six language paks.**
+
+🟡 The reading: the table is indexed by **stage number − 1**, so 29 entries
+cover S1…S29 (the numbering [that runs to S29 with S17 absent](stage-numbering-and-player-craft.md)),
+and index 25 is **S26 — the one stage with its own HUD configuration**. The
+arithmetic is exact and the `_S26` suffix names the same stage, but nothing here
+proves the indexing, so this is **a reading, not adopted**.
+
+## 🟡 Not settled
+
+* How the 2D pak's 574 T8aD and 130 RATC entries *are* addressed, if not by
+  `name_hash` of the config path. That is now the question.
+* What `HudMarkerResource.tbl` is — presumably the 13-record marker entry, but
+  the filename does not resolve, so the pairing is by content, not by hash.
+* `Parameters` (4 fields) and `Enumerate_ObjectiveMarkers` (11) are in the
+  artefact but unread here.