re: F1 dynamic attempt -- harness debugged through four bugs, still no number

Tried to close out issue #1 with an actual draw-log measurement this
iteration: built f1_hold_capture.py to boot to the settled main menu via the
proven glyph-gated route, arm the F10 UI-draw capture, hold a direction, and
read cursor position per frame -- the instrument f1-menu-repeat-harness-
built-not-answered.md already validated but never got to run against a
reachable menu.

Four bugs found across four boot attempts:

1. tap() shelled out to pad.py without this script's own env, so the press
   went to /tmp/xenia_pad.txt while Canary watched OUT/pad.txt -- an
   unobserved press indistinguishable from a dead pad. Fixed with an
   in-process tap() using the same pad() the hold uses; confirmed working
   the next run (title 154.5s, menu 163.0s).

2. ui_draw_capture_frames/max were persisted at 3/20000 from a prior
   session in xenia-canary.config.toml -- log_ui_draws is now a documented
   no-op (F10 arms unconditionally) and these two cvars didn't visibly
   respond to command-line overrides. Bumped to 600/400000 directly in the
   config.

3. The real blocker: this container has no signed-in profile (no content/
   directory at all -- a fresh container after a restart, which every
   container is right after one). Without a profile the title's sign-in
   dialog sets IsUIActive() true, which reproduces
   structures/title-a-press-fault.md's already-diagnosed unbounded-
   keystroke-queue crash -- verified byte-for-byte against that page's own
   addresses (PC 0x868 past sub_82457038, 0x828F3xxx registers, identical
   host/guest address arithmetic), looping continuously from before F10 was
   ever pressed. Fixed by creating a profile (--create_profile_if_none) and
   signing in (--logged_profile_slot_0_xuid), matching boot_menu.sh, which
   already did this and so never hit it. Confirmed: zero crashes with the
   fix, dozens per run without it.

4. Found but not re-verified: no xsetroot blank before launch, so a stale
   X-root frame from a killed prior run gave a false "TITLE" read at 2.6s,
   before any real window existed -- skip_intro.sh already blanks the root
   for exactly this reason. Fixed in the script.

Ran out of budget before a clean end-to-end run landed. Still no number for
issue #1 -- the Port keeps -1.0. Flagged prominently (HANDOFF, REFUTED.md)
because bug 3 will hit any bare run-canary invocation in any fresh
container, not just this script.

docs/re/REFUTED.md

@@ -1094,3 +1094,16 @@ attached to a right direction; only the reason is refuted here.
   emulator needed — or re-run with a repeat-capable file driver and read
   cursor position off the draw log per frame, not a coarse screen-diff.
   [`f1-no-repeat-was-the-harness.md`](f1-no-repeat-was-the-harness.md) ⟨harness⟩
+* "F10-arming a UI draw capture is safe on any settled screen" — **implicit
+  in every prior use of it, and false in a fresh container.** A `run-canary`
+  launch with no signed-in profile (every container right after a restart —
+  no `content/` directory exists yet) reproduces
+  [`structures/title-a-press-fault.md`](structures/title-a-press-fault.md)'s
+  already-diagnosed `IsUIActive`/unbounded-keystroke-queue crash in a tight
+  loop, starting before F10 is ever pressed — it is the profile, not the
+  hotkey. Reproduced byte-for-byte against that page's own addresses (crash
+  PC `0x868` past `sub_82457038`, registers in the `0x828F3xxx` input-manager
+  range, `0x1701D0000`→`0x701D0000` host/guest arithmetic identical).
+  `boot_menu.sh` already signs in a profile; a bare `run-canary` call, like
+  `f1_hold_capture.py`'s first drafts, does not, and hits this every time in
+  a fresh container. [`f1-hold-capture-harness-debugged.md`](f1-hold-capture-harness-debugged.md) ⟨environment⟩