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/port/HANDOFF.md

@@ -6593,3 +6593,17 @@ the coarse screen-diff detector undercounted" reading over the
 Keystroke/400-100ms one, though neither is confirmed yet and the actual
 producer still isn't found. Still no number — still don't take one from
 here.
+
+## 🔴 F1 dynamic attempt this iteration — harness debugged through four bugs, still no number
+
+[`docs/re/f1-hold-capture-harness-debugged.md`](../re/f1-hold-capture-harness-debugged.md).
+Tried to actually run the measurement this time. Found and fixed three real
+bugs (an env mismatch that silently dropped a scripted press, a stale
+persisted capture-window cvar, and — the big one — a fresh container with no
+signed-in profile reproducing the already-documented
+`structures/title-a-press-fault.md` crash in a loop) and found-but-didn't-
+re-verify a fourth (a stale X-root frame giving a false-positive screen
+read). Ran out of iteration budget before a clean end-to-end run. **Still no
+number for you** — keep `-1.0`. The harness should work next attempt;
+flagging for whoever's container hits the same profile-crash first, since
+every fresh container starts with none.