nvx-rs: prove shared host and guest mechanics through two independent adapters #545

Parent: #535. Phase 9 (shared-core adoption and conformance). A second test-adapter seam can start alongside the host/guest/exec foundations #538, #539 and #537. Actual independent downstream cold integration follows runnable #541; full platform-restore and region parity follow #543/#544. Foundation issue closure requires its own composable tests, not this later production-adoption evidence. This issue does not add a second application transport to NVX's small static guest library.

Goal

Prove that the same pinned nvx-rs host and guest core is actually used by two independent callers: the runnable NVX-only implementation (NVXC) and a downstream host/guest adapter with a different application transport and product-managed image/authorization/state surfaces. Sharing only types, mocks, or a model crate does not satisfy this phase. The second caller must use the shared root/process/stdio/mapping/network/VM mechanics instead of maintaining parallel implementations.

Public API and ownership boundary

• Expose small typed host plans (VM topology, ExportPlan, enforced network policy, object-pinned versus live-path grants and opened-attachment receipt) and guest inputs (image-layer/upper choice, ordered HostMap, activation identity, process/stdio handles) without depending on a product schema, registry, error model, protobuf/ttrpc, OCI runtime or VMM owner of another deployment mode.
• Keep authorization of exposed host roots/proxy services, image reference resolution, product persistence and user-facing error translation in the caller; reusable NVX validators and VMM enforcement cannot silently replace product permission checks.
• Build a static guest from --no-default-features --features guest without pulling the host feature, host Tokio, transport adapters or container runtimes into the guest. The standalone NVXC adapter and an independently built downstream adapter use one exact pinned NVX source/ABI and matched host/guest bundle; no per-exec capability probes or large start/exec-path hashes.
• Publish transport-independent conformance vectors and a tiny adapter/test seam, not another production RPC stack in the core. Record which duplicated host process/platform/policy and guest root/process/credit components a downstream consumer actually replaces; do not claim whole-file deletion where product adapter logic remains.

Staged acceptance

• Two independent callers build and execute cold, no-map/no-network (including OpenVMM prerequisite: omit dormant virtio-fs on direct no-map cold boots #547's actual no-virtio-fs VMM/guest inventories), mapped RO/RW/denied-path with OpenVMM prerequisite: verify and receipt opened host attachments #548 opened-object receipts, and network/proxy/forward scenarios with the same NVX plan/root/process/credit implementation. Product authorization is explicitly supplied and fails closed in both.
• Both exercise validation/provision rollback, authenticated guest identity and Ready, one-active-exec/finite admission, stdin larger than its window, more than 1 MiB total output, EOF, cancel/drop, timeout, priority Stop, bounded logs, deprovision/reconnect and verified recovery with the same semantic conformance vectors. Separate local NVXC processes prove cross-process queue bounds and the verified force-stop fallback when active exec holds the broker slot; another adapter may stop gracefully when its transport permits. Normal exit/cancel/timeout settles all workload descendants and inherited pipe writers before readmission; failed settlement blocks further exec or tears down the verified VM. Transport bytes and user-facing error codes may differ; shared outcomes and policy decisions do not.
• After nvx-rs: prove cross-image platform restore with pre-ready activation RPC #542/nvx-rs: reuse a platform template across mapped paths and network policies #543, both run cross-image and cross-policy pre-workload platform restore for both upper classes from the same versioned one-image0 contract, with separate immutable upper/topology keys, zero mappings/no network and explicit teardown on failure. Both reject a second image slot and mismatched old four-slot templates; direct-image cold boots still omit slots. Reuse shared template capture/key/receipt/quarantine mechanics rather than building a second cache. After nvx-rs: replace activation RPC delivery with an uncaptured VMM configuration region #544, both cold and restored paths use the final region semantics without moving large map tables into captured RAM.
• Source-bound comparisons report cold-to-Ready, restore-to-Ready and exec-start p50/p95, guest static ELF/initramfs size and bounded in-flight memory/RSS for the same resource/input cases. Set and record regression budgets before declaring parity; do not claim speed from a skipped check or a different image/VMM pin. The no-map/no-network single-workload cold path does not pay for extra filesystem/NIC/slot devices or work reserved for mapped/networked cases.
• A consumer-facing integration record identifies actual duplicate mechanics removed and the retained product adapters without disclosing private source or tenant data in this public issue. Both integrations pin compatible source, artifacts, hypervisor and guest ABI; no ignored hypervisor test is counted as acceptance.