nvx-rs slimming 4.1.1: public-API tests, and smoke tests on real VMs #1118

Parent: #1086, in #1076. Needs: #1099, #1100, #1102, #1104, #1105, #1111, #1113, #1114, #1117. Unblocks: #1119, #1130. No PR of this group merges before the API-ready commit.

Goal. NVX's tests no longer need the test adapter. CI builds each feature set; compile-only examples in nvx-rs/examples/ cover the documented host and guest paths; checklist tests in nvx-rs/tests/ cover the documented security requirements; a case matrix gives each old test a fate; and smoke tests on real VMs prove cold boots and snapshots end to end, including the CLI's 12 cold cells (#624).

Notes.

• The guest example has no public space. Its space steps compile in nvx-init.

PRs, in order. Each PR has one goal, leaves dev green, and names in its description each old test of its area as kept, rewritten or retired, with each change that check_test_changes.py reports. Its tests follow the repository's test layout: a module's unit tests, and the code that only they use, sit in its tests.rs or tests/ and move with it. The estimates count core lines (code, not comments, docs or tests) and counted files; each PR records its measured values. Each PR does what its Scope says and no more: a case, input or layout that its Scope doesn't name, and whatever "Not in this PR" lists, is out of scope. Address every review comment within the scope, and ask before acting on one that asks for more. A PR whose measured core lines pass the stop that its Estimate names (twice the estimate, at most 600) stops and asks before continuing.

1. SL5.1a: Every feature set builds, the documented examples compile, and every old test has a fate.

   • Objective: The replacement acceptance suite proves the final public surface without depending on the test adapter. It builds every feature set, compiles the documented examples and records a disposition for every existing adapter, CI and documentation test before any coverage is removed.
   • Contents: CI builds each feature set (host, guest, serde, cli, testing and no default features, of which SL0.4 added cli and testing); compile-only host and guest examples live in nvx-rs/examples/; the security checklist tests live in nvx-rs/tests/. The guest example omits the space, whose steps compile in nvx-init as a unit test of the private space. A short checklist test covers each security requirement that the docs of filesystem, vm and snapshot state: the path rules, the image checks (users keep image directories writable only by their own account), the stability of exported paths, and the launch's liveness, endpoint-owner, recovery and scratch claims. The case matrix, in the repository, lists each test of the adapter, of CI and of the docs as kept, rewritten or retired, by name. The matrix lists today's 156 adapter cases, the two that dev added among them, and the current microVM scenarios, from the current manifests and workflows.
   • Scope:
     • CI builds nvx with each of host, guest, serde, cli, testing and no default features, denying warnings; SL0.4 added cli and testing, and serde alone is new here.
     • Compile-only host and guest examples live in nvx-rs/examples/; the guest example omits the private space, whose steps compile in nvx-init as a unit test.
     • Security checklist tests in nvx-rs/tests/ cover documented filesystem path rules, image-directory ownership, stable exported paths, and launch liveness, endpoint-owner, recovery and scratch obligations.
     • A repository case matrix names all 156 adapter cases, including the two current additions, plus current CI, documentation and microVM cases, each marked kept, rewritten or retired.
   • Not in this PR:
     • A new test framework or runner: use Cargo checks and the repository's existing CI mechanisms.
     • The guest space as public API: it is nvx-init's private reference implementation.
     • Real-VM cold-boot or snapshot execution: SL5.1b and SL5.1c add those smoke tests.
     • New coverage categories, budgets or exhaustive combinations beyond the named checklist and case matrix.
     • Deleting adapter code or gates: SL5.2 does that after this group's replacement tests pass.
   • Approach: Add the fixed CI command for serde alone, the one named configuration that CI doesn't build yet, compile-only examples under nvx-rs/examples/, and focused checklist tests under nvx-rs/tests/. Reuse the documented examples rather than building a harness. Compile the guest space steps as an nvx-init unit test. Generate or maintain the matrix from the current manifests, workflows and adapter scenario list as a fixed inventory; do not create discovery infrastructure.
   • Done when:
     • CI builds nvx with each of host, guest, serde, cli, testing and no default features, denying warnings.
     • The documented host and guest examples compile, with the guest space steps checked in nvx-init.
     • Each named security obligation has its short checklist test in nvx-rs/tests/.
     • Every adapter, CI, documentation and current microVM case has one named disposition in the matrix.
   • Needs: SL4.3, in nvx-rs slimming 3.2.1: NVXC asks for a capture and activates a restore, and a blocking driver restores #1113; SL2.8b, in nvx-rs slimming 2.2.1: a VM is created in a private directory, with its restore-ready listener, then spawned #1099; SL2.11b, in nvx-rs slimming 2.2.2: a VM stops only with a proved exit, and can be reattached #1100; SL2.14, in nvx-rs slimming 2.3.2: snapshots have one strict format, and a capture finishes into it #1102; SL7.1b, in nvx-rs slimming 2.4.1: the guest's space becomes reference code, with runtime mounts, one switch and the view #1104; SL7.4b, in nvx-rs slimming 2.4.2: activation holds no fence, and a capture is one guest call #1105.
   • Estimate: 50 core lines (CI), 2 counted files. Past 100 core lines, stop and ask before continuing.

2. SL5.1b: Cold boots work end to end on real VMs.

   • Objective: The final cold-boot paths are exercised on actual hypervisors before the adapter is removed. The smoke lane proves the public create, spawn, reattach and stop lifecycle and the twelve supported CLI combinations.
   • Contents: Smoke tests in the existing VM lane: create, spawn, reattach and stop. the CLI's 12 cold cells: EROFS and GPT, with a scratch or RAM upper, on KVM, MSHV and WHP (nvx-rs: final acceptance for the image-backed runtime #624). Today's real-VM cold scenarios (managed-exec-config, sandbox-lifecycle, sandbox-proxy-only and sandbox-ram-upper) keep running, or get a fate.
   • Scope:
     • Test-only changes in the existing real-VM lane and its current microVM harness.
     • One lifecycle smoke path covering create, spawn, reattach from saved caller values, and stop.
     • The twelve cold cells: EROFS and GPT, each with a scratch or RAM upper, on KVM, MSHV and WHP.
     • The existing managed-exec-config, sandbox-lifecycle, sandbox-proxy-only and sandbox-ram-upper scenarios, each retained or assigned a disposition in the case matrix.
   • Not in this PR:
     • A new VM harness, runner pool or test framework: extend the existing real-VM lane.
     • Snapshot capture or restore coverage: SL5.1c owns those cases.
     • Additional filesystem formats, upper types or hypervisors: the acceptance matrix has exactly twelve cells.
     • Recreating retired adapter scenarios or broadening the smoke tests into exhaustive fault injection.
     • Production API or CLI behavior changes: this PR is test-only.
   • Approach: Express the twelve cells as the fixed product of the two named root formats, two named uppers and three existing backends, using the current VM lane and harness. Reuse the four public sandbox scenarios where they already prove a cell or lifecycle step; do not introduce a matrix abstraction beyond what the existing harness needs.
   • Done when:
     • The real-VM smoke test creates, spawns, reattaches to and stops a VM through the public API.
     • All twelve EROFS/GPT, scratch/RAM-upper and KVM/MSHV/WHP cold cells pass.
     • The four named current cold scenarios still run or have explicit dispositions in the case matrix.
   • Needs: SL5.1a, above; SL3.4b, in nvx-rs slimming 3.1.6: a managed sandbox run, and one exec at a time #1111.
   • Estimate: 0 core lines (tests), 1 counted file.

3. SL5.1c: Snapshots work end to end on real VMs.

   • Objective: Strict snapshots are exercised end to end on actual hypervisors before the old adapter disappears. The tests prove capture, validation and restore with nvx-init, serialized concurrent restores, preserved network behavior and useful failure attribution.
   • Contents: Smoke tests: capture, open and restore, with nvx-init as the guest; concurrent restores of one snapshot under the CLI's lock. A failed restore reports its attribution. Today's snapshot-core, snapshot-tiers and untiered-network-policy scenarios are rewritten on strict snapshots, or retired only in their raw-snapshot parts; the restore's DNS, egress, forwards and publication stay covered.
   • Scope:
     • Test-only changes in the existing real-VM lane and its current microVM harness.
     • Capture, Snapshot::open and restore of a strict snapshot, with nvx-init as the guest.
     • Concurrent restores of one snapshot while the CLI holds that snapshot's exclusive lock.
     • A failed restore whose reported error identifies its attribution.
     • Rewrite snapshot-core, snapshot-tiers and untiered-network-policy for strict snapshots, retiring only raw-snapshot portions while retaining DNS, egress, forwards and listener publication coverage.
   • Not in this PR:
     • A new snapshot harness or test framework: use the existing real-VM lane.
     • Raw OpenVMM snapshot support or compatibility tests: the final CLI refuses raw restores.
     • New snapshot tiers or storage policies beyond the strict snapshot behavior already planned.
     • A library-owned restore driver or lock: the CLI drives restores and owns the per-snapshot lock.
     • Production snapshot fixes unrelated to making these named smoke cases pass.
   • Approach: Adapt the three named microVM scenarios in place and use the CLI's existing snapshot command path and lock. Keep one focused failure that checks attribution, and preserve the scenarios' existing network assertions. Do not duplicate the snapshot implementation, build a parallel orchestrator or retain raw-snapshot branches merely for old coverage.
   • Done when:
     • A real VM is captured, opened as a strict snapshot and restored with nvx-init.
     • Concurrent restore attempts for one snapshot are serialized by the CLI's lock.
     • The selected failed restore reports its attribution.
     • DNS, egress, forwards and listener publication remain covered after the three named scenarios are rewritten or partly retired.
   • Needs: SL5.1b, above; SL7.7b, in nvx-rs slimming 3.3.3: nvx-init captures and restores, and boots the new launches' layered roots #1117; SL3.8a, in nvx-rs slimming 3.2.2: the CLI captures and restores named snapshots #1114.
   • Estimate: 0 core lines (tests), 1 counted file.

Tests. This group is the tests: builds of host, guest, serde and no default features; the documented host and guest examples, with the guest space's steps compiled in nvx-init; checklist tests for the security requirements in the docs of filesystem, vm and snapshot; the case matrix; smoke tests that create, spawn, reattach and stop a VM; the CLI's cold cells; and smoke tests that capture, open and restore a snapshot with nvx-init, run concurrent restores under the CLI's lock, and check a failed restore's attribution.

Done when: every PR above has merged, with dev green; every feature set and documented example compiles; the case matrix gives every old test a fate; and the real-VM smoke tests pass.