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/structures/isl-condition-builtins.md

@@ -335,6 +335,60 @@ offsets recur, and the one ISL-region hit that looked promising
 (`0x82273400 lwz r11, 360(r11)`) is a **vtable slot 90 call** — `r11` is the
 vptr — which is built-in 123, consistent with the known mapping.
 
+### ✅🔴 (2026-08-27) The values: the config is an **INI**, it ships nearly EMPTY, and every stage takes the defaults
+
+🔴 **First, my own label from the previous pass is wrong.** I called
+`sub_824480D0` / `sub_82448AA0` / `sub_824482D0` an *XML* config reader because
+the pak census counts 40 `<?xml` entries. Those 40 are **XPR2 resource
+manifests** — `<RDF Version="XPR2">`, `<XBGMesh Name=… DataFile=…/>`,
+`<Texture Name=… Source=… Format="D3DFMT_DXT1_SRGB"/>` — mesh and texture
+declarations, nothing to do with game config.
+
+The real config is a **loose INI at the disc root**, `config.ini`, whose header
+comment reads *「アプリケーション/ゲームパート初期設定テーブル」* — "application /
+game-part initial-settings table" — and notes that the `SYSTEM` section holds
+settings 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` — INI section and key names.
+
+**And the shipped file is 400 bytes.** In full it has two sections:
+
+```
+[SYSTEM]
+
+[LANGUAGE]
+        = eng   ; default
+#0x01   = eng   ; XC_LANGUAGE_ENGLISH
+#0x02   = jpn   ; XC_LANGUAGE_JAPANESE
+… deu / fra / esp / ita
+```
+
+`[SYSTEM]` is **empty**, and there is no `[STAGENN_UNIT_MAX]` anywhere.
+
+| check | result |
+|---|---|
+| `.ini` files on the extracted disc | **1** — `config.ini`, 400 bytes, printed in full |
+| `[STAGENN_UNIT_MAX]` sections in it | **0** |
+| `UNIT_MAX` in any pak entry | **0** |
+| `VESSEL` in any pak entry | **0** |
+
+The pak scan is **controlled**: the same loop over all 41 paks decompressed
+**26 443 entries** and found `MSG_DEMO` 192×, `mapmesh_box_500km` 162× and
+`<?xml` exactly 40× — the census number. So the reader works and the absence is
+real. (An earlier hand-rolled scan used `s[8:]` instead of `s[10:]` for the `Z1`
+header and searched the index file rather than the `.pNN` data — that one's null
+result was worthless.)
+
+> ⇒ **The lookup always misses, so every stage runs on the defaults:
+> `PLANE = 200`, `VESSEL = 20`.**
+
+🟡 A hash search was run too, in case the section were name-hashed like a pak
+entry: `name_hash("STAGE01…33_UNIT_MAX")`, `name_hash("PLANE")`,
+`name_hash("VESSEL")` — **0 hits as pak entry keys**. Eight of the 35 hashes did
+appear as 4-byte words *inside* entries, seven of them in the 1.1 GB `sound.pak`;
+that is the chance rate for a 32-bit needle in a blob that size, not a finding.
+
 🟡 Its neighbours belong to the same cluster: `builtin103` reads
 `[phase+10156]` and `[phase+10152]` (9 and 7 writers), and a sibling vtable stub
 clears `[phase+10152]`. The shape is an engine→script status trio, but that is a