Snapshot/restore workstream, stage 2: the OpenVMM changes #835

Parent: #833. Needs: nothing else in this workstream; each change proceeds in OpenVMM without waiting for stage 1.

Goal. The four OpenVMM changes that platform clones need, each in its own issue. Each reaches NVX through a PR that moves NVX's OpenVMM pin and adds VMM-level snapshot scenarios, as #801 does for #796. Everything else that clones need already works in today's OpenVMM (below).

Zero fill, expected behavior (#856):

• distro:
  • A platform restore presents the template's distro capacity, the placeholder's size, before any vCPU runs.
  • Reads inside the image go to the image. Reads past its end return zeros, including a request that crosses the end. Nothing resizes, pads or writes the image file.
  • An image longer than the capacity, or with different logical or physical block sizes, is refused.
• Scratch:
  • A platform restore may declare its fresh scratch absent, explicitly. OpenVMM then attaches the scratch device with no file, at the captured length and block sizes, taken from the manifest.
  • Reads return zeros, and writes fail with an I/O error. The guest negotiated the device as writable at the template's boot, and restore compares the access, so the device stays writable: its writes are refused, never dropped or kept in host memory. A tmpfs clone never writes to it.
  • Only a fresh scratch, the platform tier's, may be absent. A scratch file, when given, keeps the exact captured length.

Today a disk's size is its file length (openvmm/openvmm_entry/src/storage_builder/microvm.rs:247), and every snapshot-capable disk needs a nonempty raw file (:190-197, :248-251). Restore compares every disk field exactly, including the access, the length and the block sizes (openvmm/openvmm_helpers/src/snapshot/microvm.rs:1633-1647), and a fresh-scratch restore requires a scratch file (openvmm/openvmm_entry/src/microvm/restore.rs:369-374). On Linux the physical block size is the backing filesystem's (storage_builder/microvm.rs:256), so images, the placeholder and scratch files must live on filesystems with the same block size. A GPT image on the larger presented disk passes nvx::gpt, which only requires the backup header to lie inside the disk (nvx-rs/src/gpt/mod.rs:591-593).

CPU targets (#796, #801): OpenVMM already brings a CPU prefix online at restore (maxcpus=B at capture, then --restore-processors N), but the platform allowlist refuses maxcpus=. #801 admits one canonical maxcpus= token, and suspends the authentication deadline while host input is gated.

Network policy (#536): restore requires the captured policy today (openvmm/openvmm_helpers/src/snapshot/microvm.rs:579-606), and every snapshot refuses ingress, explicit host loopback and forwards (openvmm/openvmm_entry/src/cli_args/microvm.rs:731-739, :1225-1247). #536 lets a clone of a template captured with a complete deny-all policy get its own policy, installed before any vCPU runs. A template NIC is needed only for clones with network; clones without network come from templates without a NIC.

Aggregate export (#540): at restore, a dormant filesystem slot accepts only one --mount directory (openvmm/openvmm_entry/src/microvm/filesystem.rs:983-995), although OpenVMM builds aggregates for cold launches, and restores one that a snapshot captured (openvmm/openvmm_entry/src/microvm/config.rs:570-628, filesystem.rs:997-1027). #540 lets a platform restore attach an aggregate of directories and files to the dormant slot, with its hidden, re-exposed and writable paths and its owner mode, validated as at a cold launch. The guest learns of the export from the activation record, so OpenVMM exposes no layout, and the saved command line doesn't change.

Used as it is (pinned OpenVMM 79a501b6):

Acceptance. Each change is merged in OpenVMM with its VMM tests, and NVX's pin includes it.