qemu: real-image milestone — boot an actual flare-edge build in the VM

mkimage gains --rootfs-image/--oem-image (raw ext4 matched pair placed
into slot A, size-checked fail-closed; slot B keeps the skeleton as a
known-good fallback), and stage-1 rc now hands the live devtmpfs to the
new root across switch_root — busybox switch_root moves nothing, our
skeleton init remounted defensively, but a REAL image's getty opens
/dev/console immediately and looped on ENOENT without it.

Verified with the 2026-08-24 flare-edge build (rootfs 192M + oem 26M):
the image's own rcS chain runs on the 6.18 virt kernel, real daemons
start (warden-modbus confirmed running via root shell; the shipped
0.2.4 flared reproduces flare-edge#106 exactly, and S99hciinit reports
the issue-#4 btlpm symptom — the VM doubles as a faithful reproducer of
known field bugs), and a getty answers on the console.
qemu/tests/real-image-boot.sh asserts switch_root + daemon starts +
login prompt, credential-free. REAL-IMAGE-BOOT-PASS.

Regression sweep after the shared-path changes: OTA-APPLY-PASS,
PORTAL-SCENARIO-PASS, UI-SHOT-PASS, boot smoke OK.

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

qemu/rootfs/etc/rc

@@ -39,5 +39,12 @@ if ! command -v switch_root >/dev/null; then
     return 0
 fi
 
+# Hand the live devtmpfs to the new root: busybox switch_root moves nothing,
+# and a REAL device rootfs's init expects /dev to already be there (its getty
+# opens /dev/console immediately). Our own skeleton init remounts devtmpfs
+# defensively either way.
+mkdir -p /mnt/dev
+mount -o move /dev /mnt/dev 2>/dev/null || mount --move /dev /mnt/dev
+
 echo "rc: switching root to rootfs${slot} ($root)"
 exec switch_root /mnt /sbin/init