re: every weapon placed (declared x mounted, 131); a fourth undeclared table

Partitioned all 131 Weapon.ID records against the two data routes by which a
weapon is ever named - a field name in an EnumWeapon record, and a Turret_NNN
record's WeaponID value:

                    mounted   not mounted
  declared            105         22
  not declared          0          4

105 + 22 + 0 + 4 = 131, with no unexplained cell. Both marginals re-derive
unit-substructure-records' own numbers independently: mounted 105, and
22 + 4 = its "26 weapons no turret mounts".

The empty cell is the result: nothing is mounted without being declared, 0 of
131, so declaration is the superset of mounting. The four undeclared and
unmounted records are therefore reachable by neither route. Each appears
exactly once per pak copy (x6) and only as a Weapon record's ID value; the live
control Weapon_TCAF_DeltaSaber_Beam appears x18 as an EnumWeapon field name and
x228 as a Turret_NNN.WeaponID. That places Weapon_TCAF_DeltaSaber_Laser_Ttrl,
the weapon this pass set out to find, and unifies all four as orphan datasheet
rows.

Recorded as powerless rather than as evidence: the image holds 0 exact strings
for the four, but also 0 for the live control and 0 for Weapon_NULL. Only three
Weapon_-prefixed strings exist at all and 0 contain Ttrl - the executable names
no weapon, so the negative does not discriminate.

New: sweeping EnumWeapon RECORDS rather than the three declared tables gives 130
distinct field names, not 127. The extra three come from a fourth record, pak
key 305595319, resolved as EnumWeapon_TestS01.tbl, carrying Weapon_TestS01_Gun/
_Laser/_Missile. It dangles at both ends - no stage declares it, and its three
weapons are the only declared names with no Weapon.ID record. 130 - 3 = 127
restores the previous pass's union.

All fifteen artefacts byte-identical.

docs/re/BACKLOG.md

@@ -6224,3 +6224,39 @@ has not been shown.
 already in `unit-substructure-records`' "26 weapons no turret mounts", so they
 are unmounted **and** undeclared; `_Laser_Ttrl` is not on that list and is the
 one still to place.
+
+---
+
+## ✅ 2026-08-28 — every weapon placed; and a fourth, undeclared weapon table
+
+Item (a): place `Weapon_TCAF_DeltaSaber_Laser_Ttrl`.
+
+✅ **The declared × mounted partition of all 131 `Weapon.ID` records has no
+unexplained cell**: declared+mounted **105**, declared+unmounted **22**,
+undeclared+mounted **0**, undeclared+unmounted **4**. Both marginals re-derive
+`unit-substructure-records`' own numbers independently (mounted 105; 22+4 = its
+"26 weapons no turret mounts").
+
+🔑 **Nothing is mounted without being declared (0 of 131)** — declaration is the
+superset. So the four orphans are reachable by neither data route; each appears
+only as a `Weapon` record's `ID` value, ×6 (one per pak copy), and nowhere else.
+Control `Weapon_TCAF_DeltaSaber_Beam`: ×18 as an `EnumWeapon` field, ×228 as a
+`Turret_NNN.WeaponID`. That places `_Laser_Ttrl` and unifies all four as orphan
+datasheet rows.
+
+⚠️ **A route with no power, recorded so it is not re-run:** the image holds 0
+exact strings for the four — and also 0 for the live `Weapon_TCAF_DeltaSaber_Beam`
+and 0 for `Weapon_NULL`. Only three `Weapon_`-prefixed strings exist at all, and
+0 contain `Ttrl`. The executable names no weapon; the negative does not
+discriminate.
+
+✅ **New: a fourth `EnumWeapon` record** — pak key **305595319**, resolved as
+**`EnumWeapon_TestS01.tbl`**, three fields (`Weapon_TestS01_{Gun,Laser,Missile}`).
+Sweeping records rather than declared tables gives **130** names, not 127;
+`130 − 3 = 127` restores the earlier union. It dangles at both ends: **no stage
+declares it**, and its three weapons are the only declared names with **no
+`Weapon.ID` record**.
+
+🟡 Not settled: why those four were kept on the disc; whether the debriefing code
+selects the `EX_` key list for challenge missions; which challenge stage is which
+leaderboard mode.

docs/re/structures/weapon-struct-runtime.md

@@ -310,3 +310,61 @@ definition whose fields the disc defaults — craft/`UNIT` stats, which the Hang
 UI exposes only as a `Gross Weight` class and which
 [the menu route could not reach at all](../weapon-datasheet-runtime.md), are the
 obvious next target.
+
+## ✅ Every weapon placed: declared × mounted, 131 with no unexplained cell
+
+The previous pass left four weapons "declared by no table". Partitioning all
+**131** `Weapon.ID` records against the two routes by which a weapon is ever
+named in data — a field name in an `EnumWeapon` record, or a `Turret_NNN`
+record's `WeaponID` value — closes them:
+
+| | mounted on a turret | not mounted |
+|---|---:|---:|
+| **declared** by an `EnumWeapon` table | **105** | 22 |
+| **not declared** | **0** | **4** |
+
+`105 + 22 + 0 + 4 = 131`. Two independent checks land exactly:
+
+* **105 mounted** re-derives [unit-substructure-records](unit-substructure-records.md)'s
+  own "`Weapon.ID` 131, mounted 105" from a different direction.
+* **22 + 4 = 26** re-derives that document's "The 26 weapons no turret mounts".
+
+🔑 **The empty cell is the result.** *Nothing is mounted without being
+declared* — 0 of 131. Declaration is the superset of mounting, so the four
+undeclared-and-unmounted records are reachable by **neither** data route:
+
+```
+Weapon_TCAF_DeltaSaber_Laser_Ttrl      Weapon_TCAF_DeltaSaber_NoseGun_Ttrl
+Weapon_TCAF_DeltaSaber_NoseGun_None    Weapon_ADAN_Attacker_S_GunTurret
+```
+
+That places `Weapon_TCAF_DeltaSaber_Laser_Ttrl`, the one this pass set out to
+find, and unifies all four: **orphan datasheet rows.** Sweeping every archive,
+each appears exactly **once per pak copy (×6) and only as a `Weapon` record's
+`ID` value** — never as an `EnumWeapon` field, never as a `WeaponID`, never
+anywhere else. The live control `Weapon_TCAF_DeltaSaber_Beam` behaves completely
+differently: ×18 as an `EnumWeapon` field name and ×228 as a `Turret_NNN.WeaponID`.
+
+### ⚠️ One route was run and has NO power — recorded so it is not re-run
+
+"Does the executable name them instead?" The image contains **0** exact strings
+for all four — but it also contains **0** for `Weapon_TCAF_DeltaSaber_Beam` and
+**0** for `Weapon_NULL`. Only three strings start with `Weapon_` at all
+(`Weapon_Release`, `Weapon_NoEquipment`, `Weapon_CurrentWeapon` — UI/field keys,
+not weapon ids), and **0** contain `Ttrl`. The image names no weapon whatsoever,
+so this negative does not distinguish the four from a live weapon. **Powerless,
+not evidence.**
+
+### ✅ A fourth `EnumWeapon` table — `EnumWeapon_TestS01.tbl`, declared by nothing
+
+Sweeping `EnumWeapon` records rather than the three *declared* tables gives
+**130** distinct field names, not the 127 of the previous pass. The extra three
+come from a fourth record, pak key **305595319**, present in the same six
+archives and carrying exactly three fields — `Weapon_TestS01_Gun`, `_Laser`,
+`_Missile`. Its name resolves as **`EnumWeapon_TestS01.tbl`**.
+
+It dangles at **both** ends: **no stage declares it** (the 22 stage objects use
+only `_Test`, `_EX5`, `_Tutorial`), and **none of its three weapons has a
+`Weapon.ID` record** — they are the only 3 of the 130 declared names with no
+datasheet row. `130 − 3 = 127`, restoring the previous pass's union. A shipped
+table, referenced by nothing, naming weapons that do not exist.