nvx-rs slimming 3.1.7: the CLI uses only the new interface #1112

Parent: #1083, in #1076. Needs: #1110, #1111, #1114. Unblocks: #1121, #1123, #1131, #1132.

Goal. the CLI uses only the new interface: its downloads and session no longer use the old supervisor or instance, its sandbox commands no longer use the old launch, store or config APIs, and it parses its own options. scripts/nvx.py drives the existing nvx-rs binary, and its checks test behavior, not the old output.

Notes.

• the CLI may change its output. Behavior tests replace compatibility checks, and nvx.py's recorded outputs are recorded again.
• The helpers that phase 4 makes private stay where they are and remain directly callable inside the crate.

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. SL3.10a: The CLI's downloads and session no longer use the old supervisor or instance.

   • Objective: The CLI's downloads and control session no longer depend on the old process supervisor or instance layer. Their existing user-visible behavior remains while they use direct process and session primitives.
   • Contents: The downloads (download::{archive, git, github}) spawn their tools without the supervisor, and session uses neither host::instance nor the supervisor.
   • Scope:
     • nvx-rs/src/host/cli/download/{archive,git,github}.rs spawns tar, git and curl directly instead of host::supervisor::spawn_command.
     • nvx-rs/src/host/cli/session.rs replaces the supervisor-owned Launched type with the process, endpoint and capability supplied by host::vm; it introduces no host::instance dependency.
     • The checks in download/tests.rs, download/archive/tests.rs and download/github/tests.rs retain interruption and command-error behavior; the last file keeps the test-only Curl::plain.
     • run, sandbox exec and sandbox stop continue their existing session behavior through the replacement process references.
   • Not in this PR:
     • Changing download formats, validation, retries, repositories or authentication.
     • Changing NVXC messages, exec semantics or stop policy.
     • A new general-purpose process supervisor or command wrapper: direct standard process spawning is enough.
     • New commands, flags or output redesigns.
   • Approach: Replace the narrow supervisor calls with std::process::Command and the process handles already available from the new launch API. Adapt session attachment at its existing seam; do not copy the supervisor, introduce a subprocess framework or rewrite download logic.
   • Done when:
     • Archive, Git and GitHub downloads pass their existing behavior tests while spawning tools directly.
     • The download modules import no old supervisor API.
     • run, sandbox exec and sandbox stop work through session without host::instance or the old supervisor.
   • Needs: SL3.4b, in nvx-rs slimming 3.1.6: a managed sandbox run, and one exec at a time #1111; SL3.5b, in nvx-rs slimming 3.1.5: the sandbox lifecycle runs on the new interface and nvx-init #1110.
   • Estimate: 30 core lines, 4 counted files. Past 60 core lines, stop and ask before continuing.

2. SL3.10b: The CLI no longer uses the old launch, store or config APIs.

   • Objective: The sandbox command layer has no remaining dependency on nvx's old launch, store or configuration APIs. The CLI still uses the helpers that phase 4 makes private to it.
   • Contents: Remove the last uses of the old launch, store and configuration APIs from the sandbox commands' shared modules (sandbox::{mod, options, state} and lifecycle::mod). The CLI still uses the helpers that phase 4 makes private to it.
   • Scope:
     • Remove the last old launch, store and configuration uses from nvx-rs/src/host/cli/sandbox/{mod,options,state}.rs and sandbox/lifecycle/mod.rs.
     • Keep sandbox start, exec, stop and deprovision on the CLI's store and the host::vm paths from SL3.5b, and sandbox run on the host::vm path from SL3.4b.
     • The CLI continues to use image staging, path rules, artifacts, the policy-file reader and mount syntax directly until phase 4 makes them private to it.
   • Not in this PR:
     • Making the retained helper implementations private or rewriting them: phase 4 owns those changes after their library users leave.
     • Deleting unrelated old APIs from nvx: later removal PRs own provider deletion.
     • Changing provision, start, exec, stop or deprovision behavior.
     • New commands, flags or output redesigns.
   • Approach: Remove imports and residual calls at the four shared sandbox modules, using the new types and the CLI's store already introduced. Continue calling the retained helpers directly; do not accelerate their later visibility changes, duplicate them or add adapters for removed APIs.
   • Done when:
     • provision, start, exec, stop and deprovision retain their tested behavior.
     • The named shared sandbox modules use none of the old launch, store or configuration APIs.
     • The helpers that phase 4 makes private to the CLI remain in use at their existing paths.
   • Needs: SL3.10a, above; SL3.8b, in nvx-rs slimming 3.2.2: the CLI captures and restores named snapshots #1114; SL3.9, in nvx-rs slimming 3.1.6: a managed sandbox run, and one exec at a time #1111.
   • Estimate: 20 core lines, 5 counted files. Past 40 core lines, stop and ask before continuing.

3. SL3.11a: scripts/nvx.py drives the CLI, and its checks pass.

   • Objective: scripts/nvx.py and the microVM checks consistently run the nvx-rs binary built from nvx-rs/Cargo.toml. The checks verify the new CLI behavior rather than preserving the old text output.
   • Contents: nvx.py's CLI checks and microvm_tests.py run the nvx-rs binary built from nvx-rs/Cargo.toml where it is, through NVX_RS; the CLI checks test the new behavior, not the old output, and their recorded outputs are recorded again. The public sandbox scenarios, which now run by default, run on the binary that NVX_RS selects.
   • Scope:
     • scripts/nvx_tools/nvx_rs.py continues to build nvx-rs from nvx-rs/Cargo.toml into the existing nvx-rs/target directory and select it through NVX_RS.
     • scripts/nvx_tools/microvm_tests.py and the CLI-check harness invoke the binary selected through NVX_RS; their coverage changes in scripts/test_microvm_tests.py and scripts/test_nvx_tools.py, and the scenario-driver change is flagged.
     • CLI checks replace old-output comparisons with assertions of the new behavior.
     • Recorded outputs that remain meaningful are recorded again, and the public sandbox scenarios run by default against the selected binary.
   • Not in this PR:
     • Retiring scripts/nvx.py: it remains the developer tool.
     • Preserving the old CLI's wording, formatting or byte-for-byte recorded output.
     • Changing NVX_RS precedence, release packaging behavior or the nvx-rs/target location.
     • New CLI commands, flags or output redesigns beyond re-recording output produced by earlier required changes.
   • Approach: Keep the existing build command and executable selection in the Python harness, narrow output-sensitive checks to observable behavior, and refresh only the recordings they still use. Reuse NVX_RS; do not move the binary, add another selector, add a wrapper executable or preserve old output.
   • Done when:
     • nvx.py's CLI checks run through NVX_RS against the nvx-rs binary built where it is.
     • The checks assert the new command behavior instead of the old output, and remaining recorded outputs are refreshed.
     • The public sandbox scenarios run by default on the same selected binary.
     • The harness still builds into nvx-rs/target and honors an explicitly configured NVX_RS.
   • Needs: SL3.10b, above.
   • Estimate: 100 core lines, 3 counted files. Past 200 core lines, stop and ask before continuing.

Tests. The downloads (archive, Git and GitHub) behave as before while they spawn their tools directly, and run, exec and stop work through session without the instance or the supervisor. provision, start, exec, stop and deprovision keep their behavior once the shared modules stop using the old launch, store and config APIs. the CLI's own parsers accept and refuse exactly what nvx's parsers did, for native egress rules, loopback forwards, proxy endpoints and decimals. nvx.py's CLI checks run, through NVX_RS, against the existing nvx-rs binary, assert behavior instead of output, and their remaining outputs are recorded again.

Done when: every PR above has merged, with dev green.