nvx-rs: decide whether adapters' layered launches need OpenVMM's workload lifecycle #861

Parent: #816. Needs: nothing. Informs: #817, #818 and #821.

Goal. Decide whether layered launches keep OpenVMM's --microvm-lifecycle, and the workload identity that its managed mode requires. This covers launches by NVX's adapter and by other adapters. Record the decision here, with its follow-ups.

Today (dev d04d9fb, OpenVMM 79a501b6):

• The option: --microvm-lifecycle one-shot|managed writes nvx_lifecycle= into the guest's command line.
  • The user's command line can't set it, and a restore can't change it (openvmm/openvmm_defs/src/microvm.rs:1679-1681, :1740-1765; openvmm/openvmm_entry/src/cli_args/microvm.rs:897-899).
• What OpenVMM does with it: OpenVMM runs the VM the same either way.
  • managed requires --microvm-workload-identity, a live --microvm-control-console and --microvm-control-auth-stdin (cli_args/microvm.rs:1030-1045).
  • It labels the outcome report's operation managed in place of run (openvmm/openvmm_entry/src/microvm/report.rs:101-107).
• NVX's guest gives it meaning:
  • /init starts the managed agent for managed (guest/common/init:282-296).
  • The layered nvx-init-agent chooses between a resident agent that applies mapping tables, and one entrypoint with boot-token shares (guest/common/nvx-init-agent:650-718).
• NVX's host passes it:
  • the CLI, for sandbox provision and start (nvx-rs/src/host/cli/sandbox/lifecycle.rs:580-583);
  • LaunchSpec, for blockless VMs (nvx-rs/src/host/launch.rs:237-241).
• The test adapter drops it from its layered launches (runtime adapter: run cold sandboxes end to end on KVM, MSHV and WHP #822's PR 1): its guest replaces nvx-init-agent and never reads the token, and an adapter plan names no workload identity. Its blockless launches keep it.
• Platform templates can carry neither nvx_lifecycle= nor nvx_workload_* (openvmm/openvmm_helpers/src/snapshot/microvm.rs:2326-2350). So NVX's template mode keys on nvx_snapshot_tier=platform (nvx-rs: template mode, repair and activation in NVX's init #852), and its clones are always managed.

Questions:

1. Does NVX's layered PID 1 (nvx-rs: run NVX's layered sandbox root from a Rust PID 1 on the guest library #817) still choose between managed and one-shot from nvx_lifecycle? Or does sandbox run become a managed launch with one execution and a stop, as a template's run is (runtime adapter: template and clone operations #847)? The latter makes cold launches and clones alike.
2. If NVX's layered launches drop the token, where does the workload identity go? Today it's on the command line (--microvm-workload-identity). A clone's comes from its activation record (nvx-rs: a canonical activation record for platform clones #838), and a cold boot's record (nvx-rs: move NVX's adapter to NVXC v2 on the shared engine, with a validated Ready #821) could carry it the same way.
3. Does any adapter need OpenVMM's managed checks as a guard? If so, should OpenVMM make them independent of the workload identity?

Outcome: the decision, recorded here, and its follow-ups in #817, #818 and #821, or in an OpenVMM issue.

Not in scope: blockless launches, whose /init keeps using the token to start the managed agent.