qemu: full OTA apply scenario — write rootfs_b, flip AvbABData, boot it

Closes the loop every prior harness stopped short of, entirely
off-hardware: the real flared (WARDEN_HARD_RESET-gated build) pulls a
real signed tier-1 .wfw whose payload is a BOOTABLE rootfs stamped
0.0.2, verifies it, writes /dev/block/by-name/rootfs_b inside disk.img,
and flips the AvbABData (slot B: priority 15, 3 tries, unsuccessful —
the exact pre-first-boot arming state, round-tripped through a portal
check-in). The harness then boots slot _b and asserts the applied
version + marker are what runs. OTA-APPLY-PASS verified end to end.

- mkimage: the misc partition now carries REAL provisioned AvbABData
  (bytes mirror flare-edge's provisioning defaults) — slotctl fail-closes
  on bad AB magic before writing, which a zeroed misc tripped.
- run.sh --allow-apply / cmdline warden.fwapply: per-boot opt-in that
  makes stage-2 init export WARDEN_FW_ALLOW_APPLY=1; never the default.
- stage-2 init also exports WARDEN_HARD_RESET=0 (the CRU poke is fatal on
  virt, same class as the HPMCU probe); the harness performs the reboot.
- ADR-0006 boundary documented in the scenario and README: BCB slot
  CHOICE and the physical reset remain emulated.

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

qemu/README.md

@@ -79,6 +79,15 @@ stage-2 init when present.
   (a 200 ms hold — an instantaneous press+release lands inside one LVGL poll
   and never clicks), and asserts the frame changed. `qmp.py` is the tiny QMP
   client.
+- `ota-apply.sh <zImage>` (needs `FLARE_EDGE`) — the FULL apply loop the
+  portal scenario stops short of: a real signed tier-1 `.wfw` whose payload
+  is a bootable rootfs is pulled, verified, WRITTEN to rootfs_b
+  (`run.sh --allow-apply` gates it per boot), the AvbABData in `misc` is
+  flipped (mkimage provisions real A/B metadata), and the harness reboots
+  slot `_b` and asserts the applied version is running. The BCB slot CHOICE
+  and the physical reset stay emulated by the harness (ADR-0006 boundary);
+  the VM exports `WARDEN_HARD_RESET=0` so flared's post-apply reset surfaces
+  as a clean reported error instead of a /dev/mem fault.
 - Watchdog: `run.sh --watchdog`, arm `/dev/watchdog` in the guest, don't pet —
   the VM resets ~30 s later (verified). Do NOT combine with a flared payload
   expecting survival: flared pets only while the UI heartbeat is fresh.