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/re/REFUTED.md

@@ -413,3 +413,11 @@ neighbourhood, not just the line.
   zero on every keyframe**, while 1 762 grow back out of zero (`ptlogo_eff3.t32`
   runs 0 % → 200 %). Zero means collapsed; the renderer now draws nothing.
   [`structures/ui-rat-layout.md`](structures/ui-rat-layout.md)
+* "a Japanese-locale capture is impossible in this container, because canary has
+  no `user_language` cvar" → **mine, and refuted the next iteration.** The cvar
+  really is absent, but the language is persisted in
+  `<storage_root>/xconfig.settings` (`user.language`, BE u32 at file offset
+  `0x912`, located from three struct landmarks) and that file is writable. The
+  capture is still not *taken* — a Japanese run never reached the title in 787 s
+  — but it needs a longer run, not a rebuilt emulator.
+  [`tools/re-capture/set_console_language.py`](../../tools/re-capture/set_console_language.py)