runtime-adapter: prove two clone-restore invariants from the host side #965

Parent: #844 (PR 5 of 5), as a follow-up of #954. Baseline: #954 at b66e9439, which pins OpenVMM d2338ea2. Every link uses one of those revisions.

Goal. #844 leaves two VM cases of a clone's restore to its PR 5: no host input before the guest's repair acknowledges the restore, and no large-content read on restore, scratch included, with a positive control. #954's vm_clone checks both from the guest's side only, which cannot tell what the host did. Check both from the host's side, with positive controls, on KVM, MSHV, and WHP.

Today:

• No host input before the acknowledgement. assert_timeline (vm_clone.rs#L591-L606) checks that the clone took its reset, the host's first message, its Ready, and its start after the repair's acknowledgement, as the guest's activation probe reports them. The guest's worker serves its session only once clone::repair returned (capture.rs#L340-L364), so a message that the host sent, and that OpenVMM let through, before the acknowledgement would wait in the guest and still count as after it: the timeline cannot show that OpenVMM's gate held the input. NVX's restore sequence relies on that gate (restore.rs#L160-L164), which OpenVMM's broker enforces by reading no host input while the input is gated (broker.rs#L279-L283), and which OpenVMM's unit tests check at the device (input_gate_cancels_rx_but_keeps_tx_running).
• No large-content read on restore. a_clone_reads_no_more_of_its_disks_than_its_root_needs (vm_clone.rs#L1229-L1287) checks the guest's block statistics once the clone is ready, less than an eighth of each disk, with a read of each disk to its end as the positive control. They count the guest's requests alone: a start that hashed or copied the image or the scratch image on the host, or a VMM that read them whole, would still pass. NVX's plan unit tests fail any read of the clone's files' content (NO_CONTENT, clone/tests.rs#L51-L62), but nothing covers the adapter's start or the VMM.

Implementation:

1. No host input before the acknowledgement: a test-only delay of the repair in the adapter guest's clone mode, set by a token of the kernel command line of a template that the test captures for it, so that the host's attach, which begins at the restore-ready event, reaches OpenVMM well before the acknowledgement. The test then checks from the host that OpenVMM read none of the attach's bytes until the acknowledgement: on Linux, the attach's unread bytes at the control socket, as SIOCOUTQ reports them, remain until then, and on every backend, the attach completes only after the delay. A named pipe reports no unread bytes to its writer, so on Windows the check is the timing alone.
2. No large-content read on restore: host-side logical-read counters, cached reads included, around runtime-adapter-host start, after staging: the start process's own, which it prints as it exits, and the VMM's, read through its process: rchar of /proc/<pid>/io on Linux, and ReadTransferCount of GetProcessIoCounters on Windows. The positive control is the guest's read of each disk to its end, which must raise the VMM's count by at least the disks' lengths. Caveats:
   • OpenVMM restores the guest's memory through a copy-on-write mapping of the snapshot's memory file (prepare.rs#L110-L116), which no read counter sees, so the counters cover the disks, and the files read through read calls, not the memory;
   • io_uring reads may bypass rchar: the positive control on each backend shows whether the counter sees the VMM's reads of the disks.

Tests: the two checks in tests/vm_clone.rs, on KVM, MSHV, and WHP, in CI's microVM jobs.

Done when: merged, with both cases checked from the host on the three backends, or with the backend that cannot observe one documented in tests/runtime-adapter/README.md.