re: BLOCKED -- the 2D / READY_ROOM TOC names, three routes closed with controls

1. A different hash family.  The corpus knows three (idxd-tag-hash.md):
name_hash, tag_hash, ixud_hash.  Scoring all 5977 harvested names x 6
prefixes: GP_TITLE 8/16 and GP_PAUSE_MENU 6/11 under name_hash (the
positive controls), and tag_hash and ixud_hash explain NOTHING anywhere
-- including the paks name_hash does explain.  So they are not the TOC
function, and the unnameable pair is not keyed by a different one.
GP_MAIN_GAME_E2D stays at 0/711 under all three.

2. The executable.  sylpheed.db's strings table holds 7140 rows, of
which exactly two look like asset paths -- Data\gmicon002_2.t32 and
Data\gmicon006_2.t32, in a Data\ directory nothing else on the disc
uses -- and neither resolves in any archive.  The binary is not the name
source; it holds two strays and no table.

3. Name transformations -- 13 of them on the 419 config paths, all 0.

The container runs out here.  Those TOC keys hash names that exist on
neither the disc nor the executable in readable form.  The only lever
left is a dictionary attack using name_hash's shape (top byte = the
character-sum checksum), and that needs a plausible name corpus this
disc does not contain.  Noted as blocked rather than improvised around.

The port does not need these names: sprites and bundles are readable by
content (T8aD, RATC), and the config records already say which asset
each HUD element uses.  Only the archive-key to name mapping is missing.

Artefact +22 lines / 0 deletions; the other eight regenerate
byte-identical.

docs/re/BACKLOG.md

@@ -827,6 +827,33 @@ unknown, what evidence exists, and what the first step would be. Move an item in
   field; the stat keys in records not opened here (`MegaTons`, `BulletLimit`,
   `CrewCount`, `HP_CLASS`); why the roster lists 59 of 131.
 
+* 🔴 **(2026-08-27) BLOCKED — the 2D / `GP_READY_ROOM` TOC names: three routes,
+  all closed, each with a control.**
+  [structures/archive-naming](structures/archive-naming.md), artefact
+  `data/archive-naming.txt` (+22 lines, 0 deletions — purely additive).
+  **1. A different hash family.** The corpus knows three (`idxd-tag-hash.md`):
+  `name_hash`, `tag_hash`, `ixud_hash`. Scoring all **5 977** harvested names x 6
+  prefixes: `GP_TITLE` **8/16** and `GP_PAUSE_MENU` **6/11** under `name_hash`
+  (the positive controls), and **`tag_hash` and `ixud_hash` explain NOTHING
+  anywhere** — including the paks `name_hash` does explain. So they are not the
+  TOC function and the unnameable pair is not keyed by a different one.
+  `GP_MAIN_GAME_E2D` stays at **0/711** under all three.
+  **2. The executable.** `sylpheed.db`'s `strings` holds **7 140** rows, of which
+  exactly **TWO** look like asset paths — `Data\gmicon002_2.t32` and
+  `Data\gmicon006_2.t32`, in a `Data\` directory nothing else on the disc uses —
+  and **neither resolves in any archive**. The binary is not the name source; it
+  holds two strays and no table.
+  **3. Name transformations** — 13 of them on the 419 config paths, all 0.
+  🔴 **The container runs out here.** Those TOC keys hash names that exist on
+  neither the disc nor the executable in readable form. The only lever left is a
+  dictionary attack using `name_hash`'s shape (top byte = character-sum
+  checksum, so candidates are cheap to reject), and that needs a plausible name
+  corpus this disc does not contain. **Noted as blocked rather than improvised
+  around.**
+  ⚠️ **The port does not need these names**: sprites and bundles are readable by
+  CONTENT (T8aD, RATC), and the config records already say which asset each HUD
+  element uses. Only the archive-key ↔ name mapping is missing.
+
 * ✅ **(2026-08-27) WHICH ARCHIVES THE DISC CAN NAME — 100 % for eleven menu
   paks, **0.0 %** for all six 2D paks AND `GP_READY_ROOM`.**
   [structures/archive-naming](structures/archive-naming.md), artefact