re: the JP-locale capture is not blocked -- I stopped one grep too early

Last iteration I wrote into MISSION.md that a Japanese-locale capture is
impossible here, because user_language is DECLARE_int32 at four call
sites with no DEFINE and no entry in xenia-canary.config.toml. That is
true, and it was not the question. The language is PERSISTED:
kernel_state.cc builds XConfig over <storage_root>/xconfig.settings,
SetDefaults() only supplies a value when the file has none, and the file
is writable. Checking where a setting is stored rather than where it is
configured turned "blocked, needs a human decision" into a two-line edit.
Withdrawn from MISSION.md; METHOD and REFUTED lines added.

The field is located from struct landmarks rather than a hard-coded
offset, and the check re-runs on every invocation so it fails loudly if
the layout moves:

  music_volume 0.7f at User+449  -> BE float at 2727 -> User base 0x8e6
  language          at User+44   -> reads 1 (kEnglish) at 0x912
  country           at User+64   -> reads 103 (US) at 0x926

XLanguage::kJapanese = 2 (xbox.h:307). set_console_language.py wraps it
with a backup and a --restore.

The capture itself is still NOT taken, for a smaller reason than I
claimed. A run with the locale set to Japanese booted fine but never
reached the title in 787 s: wait_title.sh's green-(A) oracle never fired
and burst-sampling found no frame correlating above 0.18 with either
build-7 render -- the run sat in the attract loop. So it needs a longer
or pad-driven run, not a rebuilt emulator. Emulator stopped, lock
cleared, locale restored to English.

Nothing is decided about the keyframe-time association or the rest()
rule; this only changes what standing between us and deciding them.

docs/port/MISSION.md

@@ -77,7 +77,7 @@ alongside it.
 | **Q10** | **What are a music bank's sub-waves?** `BGM_001.slb` is three sub-waves — 10 KB, 4.47 MB, 4.67 MB — and we currently **concatenate them blindly** into one 347 s track. Two near-equal halves could be intro + loop, or two variations, or two halves of one piece. A menu that loops its music needs to know which | The role of each sub-wave, established for at least the menu BGM. "Concatenate" is a decision, not a default — right now it is a default nobody chose |
 | **S1** | ~~**Ready Room probe.**~~ **DONE 2026-08-28 — [no-go](../re/ready-room-probe.md).** It is 2D and enumerates fine, but the pak is briefing/tactical-map content, not the Ready Room menu | ✅ go/no-go written |
 
-## 🔴 Blocked in this container — a Japanese-locale capture
+## 🟡 Needs one more run — a Japanese-locale capture
 
 Recorded rather than worked around, per "do not improvise around a blocker".
 
@@ -91,17 +91,35 @@ capture of `GP_TITLE` **build 7**, the Japanese title screen.
   discriminates, `ptlogo_eff3.t32`, is also in build 7
   ([`structures/ui-resting-pose.md`](../re/structures/ui-resting-pose.md)).
 
-**Why the container cannot do it:** the console language is not settable. In this
-canary tree `user_language` appears only as `DECLARE_int32` — four call sites,
-no `DEFINE` — and it is absent from the registered cvars in
-`xenia-canary.config.toml`. There is no flag to pass, and passing an unknown one
-is specifically dangerous here: `run-canary`'s own header records that xenia
-calls `ShowSimpleMessageBox` from `ParseLaunchArguments` *before* logging starts,
-so a bad flag blocks forever on an SDL dialog with an empty log.
+**🔴 The "cannot" was wrong, and is withdrawn (2026-08-29).** It is true that
+`user_language` is only ever `DECLARE_int32` here, with no `DEFINE` and no entry
+in `xenia-canary.config.toml`, so there is no flag to pass — and passing an
+unknown one is specifically dangerous, because `run-canary`'s own header records
+that xenia calls `ShowSimpleMessageBox` from `ParseLaunchArguments` *before*
+logging starts. But the cvar is not the only route, and I stopped at the first
+one I checked.
 
-Rebuilding canary to add the cvar would be improvising around this, so it has not
-been done. **It needs a human decision**: either add the cvar and rebuild, or
-accept that both questions stay 🟡 and the port authors those values by hand.
+**The language is persisted, and canary's own file is writable.**
+`kernel_state.cc` builds `XConfig` over `<storage_root>/xconfig.settings`, which
+exists here at `/sylph-home/re/.local/share/Xenia/xconfig.settings` (6 680 B).
+`user.language` is a **big-endian u32 at file offset `0x912`**, located by three
+independent landmarks rather than guessed:
+
+| landmark | expected | found |
+|---|---|---|
+| `music_volume` (`User+449`) | `0.7f` | BE float at 2727 → `User` base `0x8e6` |
+| `language` (`User+44`) | `1` = `kEnglish`, the hard-coded default | **1** at `0x912` |
+| `country` (`User+64`) | United States | `103` at `0x926` |
+
+`XLanguage::kJapanese = 2` (`xbox.h:307`). Writing 2 there and restoring
+afterwards is using canary's own persistence, not patching its code.
+
+**🟡 Still not settled, for a smaller reason.** A run with the locale set to
+Japanese booted fine, but **never reached the title in 787 s** — `wait_title.sh`'s
+green-Ⓐ oracle never fired, and burst-sampling 8 frames found none correlating
+above 0.18 with either build-7 render. The run sat in the attract loop. So this
+needs a *longer or pad-driven* run, not a rebuilt emulator. The locale was
+restored to English afterwards.
 
 ⚠️ Neither question blocks the five menu screens. Q1's *interpolation law* is
 settled and only multi-keyframe absolute timing is open; `rest()` differs from