fix(tests/os): the rig A/B leg asserted a revert the rig's own commit gate forbids

[VijitSingh97]

The rig phase's first-ever execution (it shipped in #876 and had never run) refuted two of its own assertions. After installing v2 the leg waited for the miner on the new slot — and a rig commits on the miner running, the very event it waited for — then expected an "uncommitted" reboot to revert. The rig had already self-committed (which the leg itself proves for slot A three assertions earlier), the reboot stayed v2, and the follow-up install then targeted the wrong slot, reading the grubenv of a machine one step ahead of the script.

The leg now asserts the actual contract: the updated slot self-commits (B_OK=1 B_TRY=0, no harness hands) and persists across a reboot. Uncommitted-fallback machinery — same grub.cfg, same RAUC — stays the update phase's to prove, on an unprovisioned box where no boot path self-commits; on a provisioned rig the closing commit window is the property, not a gap. README updated to match.

Executed

Re-run on gouda against the real image after the fix:

✓ the rig self-committed the UPDATED slot (B_OK=1 B_TRY=0) — no harness hands
✓ COMMIT: the update persists on the rig across reboot
os harness: 21 passed, 0 failed

That green run is the first complete rig-phase pass — the acceptance bar on #77's rig leg (a rig booting from a stick and taking an A/B update like a coordinator) is now demonstrated, not assumed.

🤖 Generated with Claude Code