re: the config is an INI that ships nearly empty -- every stage takes 200/20

Corrects my own label: sub_824480D0/sub_82448AA0/sub_824482D0 is not an
XML reader.  The 40 <?xml pak entries are XPR2 resource manifests
(XBGMesh/Texture declarations).  The real config is a loose config.ini
at the disc root, header comment "application / game-part initial-
settings table", and every key this code touches is an INI section or
key name.

The shipped file is 400 bytes: [SYSTEM] (empty) and [LANGUAGE].  No
[STAGENN_UNIT_MAX] anywhere, and UNIT_MAX/VESSEL appear in 0 pak
entries -- so the lookup always misses and every stage runs on the
defaults PLANE=200, VESSEL=20.

The absence is controlled: the same scan decompressed 26443 entries
across 41 paks and found MSG_DEMO 192x, mapmesh_box_500km 162x and
<?xml exactly 40x, the census number.  Last iteration's null was
worthless -- it used s[8:] instead of s[10:] for the Z1 header and
searched the index rather than the .pNN data.  Using the corpus's own
reader was the whole difference.

Docs only; artefacts byte-identical.

docs/re/BACKLOG.md

@@ -627,6 +627,39 @@ unknown, what evidence exists, and what the first step would be. Move an item in
   🟡 Whether `Stage30`–`Stage33` exist on disc (33 table slots, 28 scripts) is
   still open.
 
+* ✅🔴 **(2026-08-27) THE CONFIG IS AN INI, IT SHIPS NEARLY EMPTY, AND EVERY STAGE
+  TAKES `PLANE = 200` / `VESSEL = 20`.
+  [structures/isl-condition-builtins](structures/isl-condition-builtins.md).**
+  🔴 **Correction to my own label.** I called `sub_824480D0`/`sub_82448AA0`/
+  `sub_824482D0` an *XML* config reader on the strength of the pak census's 40
+  `<?xml` entries. Those 40 are **XPR2 resource manifests** (`<RDF Version="XPR2">`,
+  `<XBGMesh>`, `<Texture … D3DFMT_DXT1_SRGB>`) — mesh/texture declarations, not
+  config.
+  ✅ **The real config is a loose `config.ini` at the disc root**, header comment
+  「アプリケーション/ゲームパート初期設定テーブル」 — "application / game-part
+  initial-settings table", noting that `SYSTEM` holds what the game and every game
+  part share. That matches every key this code touches (`SYSTEM`, `GP_SCRIPT`,
+  `SCRIPTS`, `Resource2D`, `TABLE`, `GRAPH_PATH`, `EX_FONT`, `SCRIPT_ID`,
+  `SCRIPT_PATH`, `BASE_INFO`, `PLANE`, `VESSEL`, `STAGENN_UNIT_MAX`) — they are INI
+  section and key names.
+  🔑 **The shipped file is 400 bytes**: `[SYSTEM]` (empty) and `[LANGUAGE]`
+  (`= eng` default plus `#0x01…#0x06`). **No `[STAGENN_UNIT_MAX]` anywhere**, and
+  `UNIT_MAX`/`VESSEL` appear in **0** pak entries.
+  ✅ **The absence is CONTROLLED.** The same scan over all 41 paks decompressed
+  **26 443 entries** and found `MSG_DEMO` 192×, `mapmesh_box_500km` 162× and
+  `<?xml` exactly **40×** — the census number. ⚠️ Last iteration's null was
+  worthless: that hand-rolled scan used `s[8:]` instead of `s[10:]` for the `Z1`
+  header and searched the index file rather than the `.pNN` data. **Using the
+  corpus's own reader (`unitgroup.py`) was the whole difference.**
+  ⇒ **The lookup always misses, so every stage runs on the defaults: `PLANE = 200`,
+  `VESSEL = 20`.** For the port these are hardcoded fallbacks, not per-stage data.
+  🟡 A hash search (in case the section were name-hashed like a pak entry) found
+  **0** of `name_hash("STAGE01…33_UNIT_MAX"/"PLANE"/"VESSEL")` as pak entry keys;
+  8 of 35 appeared as 4-byte words inside entries, seven in the 1.1 GB `sound.pak`
+  — the chance rate for a 32-bit needle at that size, not a finding.
+  🟡 Still open: who CONSUMES `[phase+356]`/`[phase+360]`, and whether
+  `Stage30`–`Stage33` exist on disc.
+
 ## ✅✅ SOLVED — the mission freeze was a modal sign-in dialog (2026-08-26)
 
 `XamShowSigninUI` opens a modal dialog and `xeXamDispatchDialog` blocks the