re: one A skips the intro, and NEW GAME was never a hang

Two corpus claims died in one boot, and both were costing us.

Q9's last row: a movie IS skippable with a single A. One tap ~45s into
the boot put the title up at ~57s, against a ~193s no-input baseline
measured over three boots, and Canary's own keystroke counter went 3->4
so exactly one press was delivered. The skipped-to title is fully
functional -- it draws the PRESS A plate and a second A opens the main
menu. What actually breaks the boot is hammering: the 88-press run in the
traps doc. The scripts' "tapping breaks the title" comment is too broad
and costs every scripted boot two and a half minutes.

Q4's last row: A on NEW GAME does not hang. It opens DIFFICULTY
(EASY/NORMAL/HARD/BACK, focus on NORMAL), then SELECT DATA, and only then
does the guest throw -- at PC 0x82307128, which is inside sub_823070B0,
the cache-manager STL erase this corpus already documents and which has
nothing to do with the menu path. The screen sat unchanged for 90s
because it was a menu waiting for input from a loop that never pressed
anything. That is now a METHOD line: a screen that never changes is not
necessarily hung, and the fix is to look at it and press something.

Also METHOD: never run ps -ef in this container -- all three long-lived
processes carry the entire loop prompt as argv.

docs/re/METHOD.md

@@ -169,3 +169,12 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   drive every correlation toward zero and the ranking becomes noise; one control
   frame scored 0.000 and another tied the wrong movie at 0.98. Read a dark
   frame's runner-up as *no evidence*, not as evidence for the runner-up.
+* **A screen that never changes is not necessarily hung — it may be a menu.** A
+  90-second screenshot loop that presses nothing will report a perfectly healthy
+  `DIFFICULTY` menu as a standing hang, and that reading survived in this corpus
+  for months. Before calling a static screen a hang, *look at it*, and press
+  something.
+* **Never run `ps -ef` in this container.** Each of the three long-lived
+  processes carries the whole loop prompt as its argv, so the listing is tens of
+  kilobytes of the prompt you already have. Use `pgrep -x <name>` or
+  `ps -o pid=,stat= -C <name>`.