re: the boot harness was blinking slower than the title -- diagnosed

Four consecutive runs failed to reach the interactive title, across two
locales, two launch paths and two display-gamma settings. I attributed it
in turn to a stale oracle, to the locale, and to the attract loop. It was
none of those.

  one `screenshot` call, emulator running:  10.8 s
  one `screenshot` call, emulator killed:    0.117 s

92x, measured at a 1-minute load average of 1.80 -- so it is contention
with the emulator through the X server, not background load.
skip_intro.sh takes two grabs per iteration plus a numpy import, giving a
median sampling interval of 41 s in the last run (38/82/41/20/30/30/35/
47/46/45/44/43/21/19). The title lasts "a few seconds" before the attract
loop reclaims it -- wait_title.sh's own header says so. The harness was
sampling slower than the event it was waiting for. That also explains why
runs at 16:43-18:05 the same day succeeded.

Withdrawn as CAUSES, though the observations stand: "the JP run never
reaches the interactive title", "neither locale reaches it without a pad
press", and "the game sat in the attract loop for 604 s". The English
control did control for locale -- it just shared the same defect.

Also recorded: I set kernel_display_gamma_type = 0 for the gamma control
run, which brightens the frame (mid-attract mean 122.8 vs 52.5/82.8 at
type 2) -- and skip_intro classifies movie-vs-static on an ABSOLUTE rmse
threshold, so the gamma change biased the very classifier the run
depended on. Changing a display setting and a capture behaviour in one
run confounds both. Config restored to type 2.

The fix is not applied: make the probe cheap enough to outpace the title
window (small region, no convert round trip, one long-lived process).
Every remaining emulator-side question is waiting on that.

docs/re/METHOD.md

@@ -496,3 +496,17 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   whose flat regions are pure black — every model scored ≈ 0.00 error there. That
   is not corroboration; it is a test with no power, and reporting the 0.00 as
   agreement would have dressed an untested claim as a verified one.
+* **Time your probe against the thing you are probing for.** Four runs concluded
+  "the game never reaches the title". `screenshot` costs **10.8 s while xenia is
+  running** and **0.117 s once it is killed** — 92× — so a two-grab polling loop
+  samples every ~41 s, against a title screen this corpus documents as lasting a
+  few seconds. The harness was blinking slower than the event. Before believing a
+  negative from a polling loop, measure its interval and compare it to the
+  duration of what you are waiting for; and measure the probe's cost *under the
+  same load as the run*, because idle timing here was off by two orders of
+  magnitude.
+* **Do not change a display setting and a capture behaviour in the same run.**
+  `kernel_display_gamma_type = 0` brightens the frame, and `skip_intro.sh`
+  classifies movie-vs-static on an *absolute* rmse threshold — so the gamma
+  change biased the very classifier the run depended on. Harness thresholds tuned
+  on one output configuration are not portable to another.