qemu: the bridge waits for a fresh reply instead of sleeping

The control bridge sent a command, slept 0.3 s and read /tmp/warden-ui.dbg,
so a page that took longer to build handed the host the previous command's
reply as if it were this one (flare-edge #152). It now removes the old
reply before sending and waits, up to 5 s, for warden-ui to rename the new
one into place, the same recipe tools/warden-ctl and flow-run-hw.sh use.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013aHKWzT5EF86RFKRMtAv9n

qemu/rootfs/sbin/init

@@ -195,11 +195,19 @@ if grep -qw warden.ctl /proc/cmdline && [ -c /dev/ttyS0 ]; then
                     ;;
                 *)
                     if [ -p /tmp/warden-ui.ctl ]; then
+                        # Remove the previous reply BEFORE sending, then wait
+                        # for the new one to appear (the UI renames it into
+                        # place whole). A fixed settle used to hand back the
+                        # previous command's reply whenever a page took longer
+                        # than 0.3 s to build (flare-edge #152); this is the
+                        # same recipe tools/warden-ctl uses over SSH.
+                        rm -f /tmp/warden-ui.dbg
                         printf '%s\n' "$cmd" > /tmp/warden-ui.ctl
-                        # The UI polls its FIFO every 100 ms and truncates the
+                        n=0
-                        # reply file on each command, so a short settle then a
+                        while [ ! -s /tmp/warden-ui.dbg ] && [ "$n" -lt 100 ]; do
-                        # read is the same protocol warden-ctl uses over SSH.
+                            sleep 0.05
-                        sleep 0.3
+                            n=$((n + 1))
+                        done
                         cat /tmp/warden-ui.dbg 2>/dev/null >&3
                     else
                         echo "bridge: warden-ui control FIFO not present" >&3