qemu: drive scripted UI scenarios

ui-shot.sh proves touch reaches the UI in one tap. Verifying a UI change needs
a SEQUENCE -- swipe through the app rows, open a submenu, tap a tab, bring up
the keyboard -- and booting per step costs about a minute under TCG, so:

- qmp.py gains a `drive` mode: one connection, one boot, a script of
  tap/swipe/fling/shot/sleep steps in PANEL PIXELS rather than the raw
  0..32767 tablet axis. Swipes interpolate their motion, because LVGL decides
  a gesture from the movement between indev polls and a press-then-release
  with nothing in between is a click, not a scroll.
- ui-drive.sh runs such a script against a booted VM and collects the
  screenshots.

It also FAILS on a UI that died mid-script. warden-ui crashing leaves its last
frame in the framebuffer, so screendumps keep returning a plausible picture of
a program that no longer exists; stage-2 init now announces the exit and its
status on the console, and ui-drive.sh greps for that after the run. This is
what caught the SIGSEGV behind flare-edge#125.

Stage-2 init also mounts devpts. The UI's Terminal page opens a PTY, so
without it that page could only ever report "no PTY available" -- it rendered,
which made a screenshot scenario look fine while the one thing the page does
was untestable.

tests/scripts/nav-stress.txt is the first committed drive script: the
navigation sequence that reproduces flare-edge#125.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T2D2KtdgwbhbF6Mo64eUrn

qemu/rootfs/sbin/init

@@ -13,6 +13,12 @@ exec </dev/console >/dev/console 2>&1
 mount -t proc proc /proc
 mount -t sysfs sysfs /sys
 mount -t tmpfs tmpfs /tmp
+# The UI's Terminal page opens a PTY (posix_openpt), which needs devpts mounted
+# and /dev/ptmx pointing into it. Without this the page can only ever report
+# "no PTY available" -- it renders, so a screenshot scenario looks fine, while
+# the one thing the page does is untestable in the VM.
+mkdir -p /dev/pts
+mount -t devpts devpts /dev/pts 2>/dev/null
 
 # shellcheck source=qemu/rootfs/etc/warden-lib.sh disable=SC1091
 . /etc/warden-lib.sh
@@ -93,7 +99,21 @@ done
 # virt.fragment kernel.
 if [ -x /usr/bin/warden-ui ] && [ -c /dev/fb0 ]; then
     echo "init: starting warden-ui (fbdev)"
-    /usr/bin/warden-ui > /tmp/warden-ui.log 2>&1 &
+    # Announce the exit on the CONSOLE, not just in the log. A UI that dies
+    # mid-scenario otherwise looks exactly like a UI that stopped repainting:
+    # the framebuffer holds its last frame, screendumps keep working, and the
+    # scenario reports a stale picture as the current state. With this, a crash
+    # is one grep away for any scenario driving the VM from outside, and the
+    # signal or status that caused it is on the line.
+    (
+        /usr/bin/warden-ui > /tmp/warden-ui.log 2>&1
+        rc=$?
+        echo "init: warden-ui EXITED rc=$rc"
+        # 128+n is a signal death (139 = SIGSEGV); dump the tail so the
+        # scenario's console log carries the UI's own last words.
+        echo "init: warden-ui log tail:"
+        tail -n 20 /tmp/warden-ui.log 2>/dev/null
+    ) &
 fi
 
 if grep -qw warden.shell /proc/cmdline; then