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/tests/scripts/nav-stress.txt

@@ -0,0 +1,55 @@
+# Navigation stress: the sequence that used to kill warden-ui.
+#
+# Settings > Apps reads the PROJECTED MENU TABLE (app.c's all_proj, populated
+# lazily on that page's first build). Walking the app rows writes one timestamp
+# per row into app.c's s_row_left. While that array was sized 8 and the shipped
+# registry projected 18 rows, leaving any row from index 8 up wrote past it --
+# straight over all_count and all_proj, which the linker places immediately
+# after. Coming back to Settings > Apps then walked a tick value as a `const
+# char *` and the process died with SIGSEGV (rc=139).
+#
+# So the order matters and is the whole test: populate the table, walk the late
+# rows, come BACK. A run that only walks rows never triggers it, because with
+# all_count still zero the page's lazy init quietly repairs the array.
+#
+# Run: ui-drive.sh <zImage> tests/scripts/nav-stress.txt <outdir>
+# PASS is ui-drive.sh finding no "warden-ui EXITED" on the console.
+
+echo == populate the projected menu table
+tap 47 676
+sleep 2
+tap 464 40
+sleep 4
+shot 01-apps-first
+
+echo == back to column 0, where the rail is on screen
+tap 174 40
+sleep 2
+
+echo == walk the app rows, the late ones included
+tap 47 512
+sleep 2
+tap 47 592
+sleep 2
+swipe 47 560 47 220 500
+sleep 1
+tap 47 420
+sleep 2
+tap 47 500
+sleep 2
+swipe 47 560 47 220 500
+sleep 1
+tap 47 380
+sleep 2
+tap 47 520
+sleep 2
+shot 02-late-rows
+
+echo == and back: this is the step that used to segfault
+tap 47 676
+sleep 2
+tap 464 40
+sleep 4
+shot 03-apps-again
+sleep 3
+shot 04-still-alive