re: the English control removes the locale from the title-capture problem

Two iterations framed the JP title capture as possibly locale-specific.
It is not. Same flags, same oracle, English locale: 75 samples over 734 s,
every one glyph = 0. The English boot does not present the interactive
title either. Canary was alive throughout, polling
XamInputGetKeystrokeEx (1801 calls); the frame at 734 s has content but
correlates 0.15 with build 4's render and 0.05 with the main menu -- an
attract-movie frame, not title art.

So neither locale reaches the interactive title in ~12 minutes without a
pad press. What is actually untested is the pad: pad.py and
nav_to_flight.sh exist, and title_states_capture.sh reaches title states
with a flag set this probe did not replicate (--log_ui_draws
--ui_draw_capture_frames, plus xdotool window focus). It is a capture
problem, not a locale one. MISSION.md updated.

Also resolved a caveat I had given the port agent without checking it:
"rotation is decoded but not rendered" does NOT affect their five screens
at rest. Title, main menu, EXTRAS and both splash halves have ZERO
top-level elements with a non-zero rotation. The only rotations on any of
them are the title's two nested ptloop records (r = 30 and -45), and at
rest those sit at x = 1521 and x = -839 -- a 399-wide sprite entirely off
both edges of a 1280 screen. The caveat now applies only to animating the
title build-in, where the sweeps cross the screen rotated.

Two METHOD lines: run the control before theorising about the difference,
and log every sample so a failure is a measurement rather than a silence.

Emulator stopped, lock cleared, locale English.

docs/re/METHOD.md

@@ -451,3 +451,15 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   check whether something in the toolkit already supersedes it, and run the probe
   against a known-positive capture first — `is_title.py` scores 753 on a real
   title frame and 327 on the main menu, which takes one command to confirm.
+* **Run the control before theorising about the difference.** A Japanese-locale
+  run failed to reach the interactive title, and I wrote up the open question as
+  "if English reaches it, the difference is the locale". English does not reach
+  it either — 75 samples over 734 s, every one a miss. The locale had nothing to
+  do with it, and two iterations framed the problem around a variable that was
+  never implicated. The control cost one run and would have cost the same one
+  iteration earlier.
+* **Log every sample, not just the hit.** The first probe printed nothing until
+  it succeeded, so a 787 s failure was indistinguishable from a probe that never
+  ran. Printing the oracle's value each tick turns "no title" into "75 samples,
+  max glyph 0", which is a measurement — and it is what showed the black-screen
+  and attract-movie phases were being sampled correctly all along.

docs/re/REFUTED.md

@@ -426,3 +426,7 @@ neighbourhood, not just the line.
   oracle. Re-run with `is_title.py`: the game still did not present the
   interactive title, but that is now a measured statement (zero green-glyph
   pixels, correlation ≤ 0.22 to either build-7 render) rather than an artefact.
+* "the Japanese-locale run fails to reach the interactive title *because of the
+  locale*" → **refuted by the English control.** 75 samples over 734 s with the
+  same flags and oracle, every one glyph = 0. Neither locale presents the
+  interactive title without a pad press.