docs: map where the autopilot's objective and action knowledge lives on the disc

The autopilot doc's own problem #2 is that the pilot ignores the mission
objective - its 300s run took no damage, killed one fighter, and watched
REMAINING OB RISE from 004 to 011. So this surveys where that knowledge is.

GP_TUTORIAL.pak yields the game's own list of what a player can do: BASIC
CONTROLS, HEADS-UP DISPLAY, RADAR, SUPPLY AND SPECIAL MOVES, RADIO ORDERS,
ADVANCED CONTROLS, with descriptions. Worth stating against what the pilot
actually does: pilot.py and navigator.py use move and attack only. Resupply,
special moves, radio orders to wingmen and advanced maneuvers are all unused, and
two of them bear directly on open problems - resupply is the untested RETIRE
mode, radio orders is an escort lever that flying skill does not substitute for.

tables.pak is a name-resolved config seam: 79 IDXD objects, 6275 distinct field
names, including DLG_MISSION_OBJECTIVE and DLG_STAGE_TITLE01..16 (so 16 stages).
GP_MAIN_GAME_<lang>.pak holds 131 weapon\ tables, 113 unit\ and 64 message\ -
the weapon ones being what problem #1 wants for real projectile speed and range.

But the objective TEXT is not text: DLG_MISSION_OBJECTIVE = pdscr099.prt, a
screen part, and the message tables resolve to face textures. All human-readable
text in this game is rendered sprite art, which is why the UI work has been
reading pixels all along. A per-mission objective table is an OCR job, not a
table dump - so the cheaper and more actionable route is the runtime REMAINING OB
counter, which is on the HUD and therefore in RAM.

docs/re/autopilot-knowledge-sources.md

@@ -0,0 +1,102 @@
+# Where the autopilot's missing knowledge lives on the disc
+
+**Status:** 🟡 this is a **map**, not the knowledge itself — it says which files
+hold the mission objectives and the player's action set, and what form they take.
+✅ the tutorial's capability list is extracted. 🔴 objective *text* is not stored
+as text anywhere, which is the finding that shapes the next step.
+
+[`autopilot-memory-driven.md`](autopilot-memory-driven.md) ranks its own open
+problems, and #2 is *"which targets count — `REMAINING OB` is the mission's own
+objective counter"*. A pilot that flies well but ignores the objective cannot
+finish a mission, and the 300 s run there proves it: no damage taken, one kill,
+and `REMAINING OB` **rising** from 004 to 011 as waves spawned. So before more
+control tuning, this is where the objective and action data actually is.
+
+## ✅ The player's action set, from the tutorial
+
+`GP_TUTORIAL.pak` is two RATC bundles (~5.7 MB each, one per language) holding
+the **lesson-select menu**. Decoding its 74 textures gives the game's own list of
+what a player can do:
+
+| lesson | description |
+|---|---|
+| BASIC CONTROLS | "Learn how to move and attack" |
+| HEADS-UP DISPLAY | "Learn how to use the HUD" |
+| RADAR | "Learn how to use radar" |
+| SUPPLY AND SPECIAL MOVES | "Learn how to resupply and execute special moves" |
+| RADIO ORDERS | "Learn how to radio orders to your wingmen" |
+| ADVANCED CONTROLS | "Learn advanced maneuvers for experienced players" |
+
+([lessons](captures/tutorial-lesson-list.png),
+[descriptions](captures/tutorial-lesson-descriptions.png))
+
+That is worth stating plainly against what the pilot currently does. `pilot.py`
+and `navigator.py` use **move and attack** only. Four of the six taught
+capabilities — resupply, special moves, radio orders to wingmen, advanced
+maneuvers — are unused, and two of them are directly relevant to open problems:
+**resupply** is the untested RETIRE mode, and **radio orders** is a lever on
+escort missions that no amount of flying skill substitutes for.
+
+The `_mnv*` / `_turn180` morph poses already decoded in the ship meshes
+([`saber-texture-investigation`](../../MEMORY.md)) are presumably the "special
+moves" the tutorial names.
+
+## ✅ `tables.pak` is the config seam, and it is name-resolved
+
+79 IDXD objects, **6 275 distinct field names**, all human-readable. Examples of
+what is in there:
+
+* `DLG_MISSION_OBJECTIVE`, `DLG_STAGE_TITLE01` … `DLG_STAGE_TITLE16` — so the
+  game has **16 stages** and a per-stage title, indexed;
+* `CLEAR_TIME_RANKING`, `ClearTimes`, `CLEARED`, `ConditionToDevelop`;
+* whole screen layouts (`PATH`/`BASE`/`MAIN`/`FONT_*` per screen);
+* a 5 801-field sound table (`BGM_001`…, `JNGL_001`…, `STAGES = Static.slb`).
+
+`GP_MAIN_GAME_<lang>.pak` is the other half: 1 119 objects, 308 name-resolved —
+**131 `weapon\*.tbl`**, **113 `unit\*.tbl`**, **64 `message\*.tbl`**. The weapon
+tables are the ones `autopilot-memory-driven.md` problem #1 wants for real
+projectile speed and range instead of hard-coded constants.
+
+## 🔴 The objective text is not text
+
+The obvious hope — read each stage's objective string statically and hand the
+pilot a per-mission goal — does not work as stated:
+
+```
+DLG_MISSION_OBJECTIVE  = pdscr099.prt
+DLG_STAGE_TITLE03      = pzscr02.prt
+```
+
+Those are **`.prt` screen parts**, not strings. And the `message\*` tables are
+not prose either — `CharacterCONTROLLERA` resolves to face textures
+(`pjf035_A01.t32`), i.e. portraits.
+
+That is consistent with everything else this project has found: **all
+human-readable text in this game is rendered sprite art**, which is why the UI
+work has been reading pixels rather than strings all along. A per-mission
+objective table is therefore an OCR job over screen parts, not a table dump.
+
+## What this implies for the next step
+
+Reading the objective *text* statically is possible but expensive, and it only
+yields strategy — a human-readable sentence. What actually closes a mission is
+the **runtime counter**: `REMAINING OB` is on the HUD, so it is in guest RAM, and
+finding it converts "shoot whatever is nearest" into "shoot what closes the
+mission". That is `autopilot-memory-driven.md` problem #2 and it is the cheaper
+and more actionable of the two.
+
+Per-mission strategy then has a natural shape: the static tables say **which
+stage** and how many objective targets it has; the runtime counter says whether
+the pilot is making progress; and the four unused taught capabilities — radio
+orders, resupply, special moves, advanced maneuvers — are the levers it currently
+does not pull.
+
+## Not settled
+
+* ❔ The button→action mapping. `tables.pak` has an `ID=Control` object but it is
+  a unit type (`HP_ID`, `HP_CLASS`, `Mine`), not an input map. What is known
+  (`RT` accelerate, `LT` brake, `RB` fire) came from measurement, not the disc.
+* ❔ Whether the in-flight tutorial lessons can be driven to *demonstrate* each
+  action — they would be the cheapest ground truth for the remaining inputs, and
+  the tutorial is now reliably reachable.
+* ❔ `REMAINING OB` in RAM — the next item.