re: the develop blob's index space is SOLVED -- it follows strings.tbl, cut items and all

Three hand-written probe saves settled what a mission payout could not.

  all 54 owned  -> every tab fills and the lists WRAP, giving exact counts
                   (GUN 8, BEAM 8, LASER 4, MPM 5, ASM 5, B/R 7, CANNON 6,
                   SPECIAL 6 = 43 displayed) and confirming the display order is
                   weapon.tbl's order item-for-item. It also killed the idea
                   that gate-unmet owned flags are suppressed: Maelstrom Bomb
                   (Stage 6) and Grav Cannon XGS (Stage 12) both rendered at a
                   Stage-2 save.
  only 9 + 39   -> STILETTO BG1 Developed (control) AND TOMAHAWK ALPHA RAIL GUN
                   Developed. The CANNON block starts at 39, not 38.
  only 39 + 48  -> JAMMING SYSTEM Developed. SPECIAL starts at 48, and with six
                   SPECIAL items the array closes exactly at 53, nothing spare.

So the blob is indexed by strings.tbl's item order -- the display order PLUS the
items only the localisation file carries (Adhesive Mine B2A, and three of
Ballista GSH / Designator LH / Smoke Marker Launcher / Bumble UV). They never
appear in the Arsenal but they hold slots, which is the entire reason the tail
looked broken. It also explains the retail save's five "unexplained" owned
entries at 33 and 45/46/47: cut items, shipped flagged owned, never rendered.

That weapon.tbl's No_Equipment..Wep_83 run is ALSO 54 long is a coincidence, and
it cost real time -- the two orders agree only to index 32. Recorded as such.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/re/structures/savegame-format.md

@@ -89,7 +89,7 @@ photographed against this exact save (see "Naming the fields", further down).
 | +56 | 2 | 🟡 see +36 |
 | +60 | 0 | ❔ |
 | +64 (raw 4) | `09 15 00 00` | ❔ the trailer's u32 is the **same** value |
-| +68 (raw 54) | see below | 🟡 **per-item Arsenal development state**, 54 one-byte entries, values only ∈ {0, 2, 4} — histogram `{4: 10, 2: 6, 0: 38}`. `4` = developed, `2` = developable now, `0` = still locked ([evidence](#the-develop-differential-one-weapon-three-fields)) |
+| +68 (raw 54) | see below | ✅ **per-item Arsenal development state**, one byte per item, `4` = owned, `2` = developable now, `0` = locked ([evidence](#the-develop-differential-one-weapon-three-fields)). Only the `4`s are stored state — `2` is re-derived at load. The index space is **solved**: it is `strings.tbl`'s item order, cut items included ([mapping](../arsenal-develop-economy.md)) |
 
 The 54-byte blob is the interesting one — a fixed-length array of small
 enumerated states, **16 of the 54 non-zero** (ten 4s, six 2s):
@@ -131,13 +131,13 @@ three-state progression *locked → developable → developed*, and the blob is
 Arsenal's development state, not a bitmask of owned weapons (a bitmask could not
 represent the middle state).
 
-**Which item each index is** was chased separately and is **half settled** — see
-[the Arsenal develop economy](../arsenal-develop-economy.md). In short: the index
-space is the `WEAPONS` id list in `GP_HANGAR_ARSENAL.pak :: eng\weapon.tbl`, whose
-`No_Equipment … Wep_83` run is exactly 54 long; twelve independent concordances
-confirm indices **0–31** (including all six `2`s, predicted from the disc's own
-"Conditions to obtain" text before the blob was looked at), while the tail from
-index 33 on contradicts the screen and is left ❔.
+**Which item each index is** was chased separately and is **solved** — see
+[the Arsenal develop economy](../arsenal-develop-economy.md). The index space is
+the item order in `GP_HANGAR_ARSENAL.pak :: eng\strings.tbl`, i.e. the display
+order **plus the cut items that only the localisation file lists**, pinned by four
+hand-written probe saves (indices 9, 21, 39, 48) and closing exactly at 53. The
+retail save's five otherwise-unexplained owned entries are those cut items,
+shipped flagged as owned and never rendered.
 
 One more thing this does **not** settle, and should not be written as if it did: