bootcheck: make the prompt wait survive a slow guest

Three bugs, all of which surfaced as a failed check somewhere other than
the command that was actually slow.

Wait-Prompt waited a fixed 20 s. These tests run under TCG, not KVM, and
a cold `ls /bin | wc -l` takes 23 s on the Fedora laptop measured with
the guest's own /proc/uptime -- it was over the wall every time. Raised
to 60 s; a long timeout only costs time when something is genuinely
wrong, a short one costs a false failure elsewhere.

It also matched a prompt anywhere in the transcript. Between writing a
command and the guest echoing it the log still ends with the previous
prompt, so it could return before the command had started and the next
one was typed on top of it. Anchor the match to text produced after the
command was sent.

On timeout it slept two seconds and typed regardless, which is what
turned one slow command into an interleaved transcript and a failure
attributed to a later check. Wait for output to stop arriving instead.

Report any command that never produced a prompt next to the result:
after one overrun every later check is reading a transcript that may be
interleaved, and that should not be something you have to notice in the
scrollback.

With this, -Fb -Tty -Usb -Sock -Evdev -Ps is 108 [ok], 0 misses.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

.claude/memory/schos-bootcheck-trust.md

@@ -4,7 +4,7 @@ description: bootcheck silently stopped running and five of seven modes asserted
 metadata: 
   node_type: memory
   originSessionId: 9d8a2aef-bcf0-47a0-96c6-f706efab4a95
-  modified: 2026-08-09T19:05:06.942Z
+  modified: 2026-08-09T19:17:56.770Z
 ---
 
 **A green run is only green if you counted the checks.** On 2026-08-09 the
@@ -46,16 +46,27 @@ of success. Both of these produced clean-looking runs while testing nothing.
 **How to apply:** after any change to the harness itself, verify the check
 count, not just the absence of FAIL.
 
-## The extended suite is timing-fragile on the Fedora laptop
+## The extended suite was timing-fragile — fixed 2026-08-09
 
-`Wait-Prompt` waits a fixed **20 s**; measured on this machine with the guest's
-own `/proc/uptime`, a cold `ls /bin | wc -l` takes **23 s** and took **51 s**
-before the e820 work. When it overruns, the script sleeps 2 s and types anyway,
-so the next command lands in a busy shell and the transcript interleaves — and
-the check that fails is then some *later* one whose output is no longer
-adjacent to its command. `yes writes through a pipe` failed this way while
-`y`/`y` were plainly correct in the transcript. Treat a single FAIL in
-`-Fb -Tty -Usb -Sock -Evdev -Ps` as suspect until the transcript is read.
+`yes writes through a pipe` failed repeatedly on `-Fb -Tty -Usb -Sock -Evdev
+-Ps` while `y`/`y` were plainly correct in the transcript. Three harness bugs,
+all fixed in commit 4e0478c and its follow-up:
+
+1. **`Wait-Prompt` waited a fixed 20 s.** Measured from inside the guest, a cold
+   `ls /bin | wc -l` takes **23 s** here (**51 s** before the e820 work), so the
+   wall was always crossed. Now 60 s.
+2. **It matched the prompt anywhere in the transcript.** Between sending a
+   command and the guest echoing it, the log still ends with the *previous*
+   prompt — so it could return before the command started. Now anchored to text
+   produced after the command was sent.
+3. **On timeout it slept 2 s and typed anyway**, landing the next command in a
+   busy shell and interleaving the transcript, so the check that failed was a
+   *later* unrelated one. Now waits for output to stop growing.
+
+The run also names any command that produced no prompt, because after one
+overrun every later check is reading a possibly-interleaved transcript.
+
+**Still treat a lone FAIL here as suspect until you have read the transcript.**
 
 **Leaked QEMU made this worse and is now fixed** (commit 4e0478c): the
 `finally` cannot run when the *script* is killed, so QEMU outlived it and, under