nvx-rs: clone plans refuse the templates of adapters whose guest speaks its own control contract #1010

Summary

check_template (nvx-rs/src/host/template/clone.rs) refuses every template whose key's runtime identity has a control_contract other than this build's contract::CONTROL_CONTRACT_REVISION. An adapter that boots its own guest, and drives a clone's activation through its own CloneControl, records its guest's control protocol in the runtime identity's control_contract, as it does for its cold boots. NVX then captures that adapter's templates, since capture checks no contract, but refuses every clone of them:

the template's generation N speaks other contracts than this build, which restores none of its clones (stage plan, evidence incompatible-host, outcome host)

Where

At dev (b8b82a60):

• The check: check_template in nvx-rs/src/host/template/clone.rs (lines 738–760; the control_contract comparison is line 749), added in nvx-rs: plan the clones of templates, and check their block geometry #888.
• Capture: create_template (nvx-rs/src/host/template/store/capture.rs, line 406) checks no contract, so the mismatch shows only at the first clone, as a fallback on every start.
• Launch and reattach: a clone's launch requires the template's runtime identity (Evidence::RuntimeMismatch), and reattach_clone (nvx-rs/src/host/template/clone/reattach.rs, line 163) ends a clone's VMM that runs under another identity. So an adapter can't keep its own contract for clones alone.

The workaround available today

Run templates and clones under a second runtime identity: the adapter's own, with CONTROL_CONTRACT_REVISION in place of its guest's control contract. Cold boots keep the adapter's identity. The adapter's readiness check still enforces its guest's protocol at each activation and reattach, and the identity's digests still pin the guest. But the template and clone identities then record a contract that the guest speaks only through the adapter's own framing: a label that NVX requires and doesn't verify.

Proposal

One of:

1. Compare with the control that the caller drives. Let the CloneControl implementation, or the clone request, declare the control contract it speaks. check_template then compares the template's control_contract with that, instead of NVX's own revision. NVX's own control declares CONTROL_CONTRACT_REVISION, so its behavior doesn't change.
2. Compare with the launch identity. The launch already requires the template's runtime identity. check_template could compare the template's runtime with the identity that the caller launches under, and keep the fixed revisions only for NVX's own control.

Either way:

• The boot contract and control session checks can stay as they are, unless an adapter needs the same for them.
• create_template could refuse what no clone can use, with the same rule. A template whose contracts no clone plan accepts would then fail at capture, not at every clone.

Downstream

Users of the template API that adopted the workaround above should be checked when this changes. They would move to the new declaration, and their templates would be captured again once, since the key changes.

Related: #833, #847.