nvx-rs: repair a restored clone in the guest, with an owned seed and one acknowledgment #842

Parent: #834 (#833), steps 1 and 3. Needs: #840; its VM tests run with #844. Unblocks: #843, #844.

Goal. Repair a restored clone in-process, through nvx::guest: the clocks, the memory target and the reseed, then exactly one acknowledgment. Library callers stop depending on the shell steps.

Today (dev d04d9fb):

• nvx-snapshot:
  • validates the restore packet;
  • onlines CPUs and memory blocks through sysfs;
  • reseeds through nvx-reseed;
  • derives /etc/machine-id from the first 32 hex digits of the entropy file's SHA-256, then removes the file;
  • runs nvx-time restore-finish --ack (guest/common/nvx-snapshot:108-410).
• TimeAbi::capture writes the restore entropy to the file named in CaptureRequest::new(scratch, generation_id, entropy_path) (nvx-rs/src/guest/time/api.rs:133-144, :264-355).
  • Restore carries the flags, the online-VP target, the new generation ID and the memory ranges.
  • RestoreFinish::{new, acknowledge, new_cpus} acknowledges (api.rs:787-815).
  • The restore packet is version 4 (time/decoders.rs:29-36).
• nvx::guest::reseed::reseed(&Seed) adds the seed with RNDADDENTROPY, and reseeds the CRNG with RNDRESEEDCRNG (nvx-rs/src/guest/reseed.rs:57-103). Seed isn't zeroed on drop.
• The time ABI powers off with 193, 194 or 195 (nvx-rs/src/guest/time/system.rs:19-28).

Stacked PRs. Each PR builds on the one before it, and lands with its own tests.

PR 1 of 3: the owned seed. Step 1; needs nothing.

• CaptureRequest gains an in-memory mode, in which capture returns the restore seed as an owned Seed instead of writing a file.
• Seed zeroes its bytes on drop, with volatile writes, and doesn't format its contents. It's never written, logged or exposed.
• The command tools keep the file mode.
• Tests: the in-memory mode returns the seed and writes no file; Seed is zeroed on drop; the tools' file mode is unchanged.

PR 2 of 3: repair. Step 3; needs PR 1 and #840's PR 1.

• nvx::guest::clone::repair takes the restore result from nvx-rs: capture preparation in the guest, and template mode in the test adapter's guest #840 and the targets, and returns Repaired:

  1. capture has already validated the packet and the lineage, and stepped the clock.
  2. Repair checks the memory target against the captured capacity. It adds and onlines the memory blocks through sysfs, as nvx-snapshot does, and verifies the result.
  3. It reseeds with the owned seed through reseed::reseed, then drops the seed.
  4. It calls TimeAbi::restore_finish once, with the acknowledgment. It records its progress, so that it never acknowledges twice, even when the caller retries.

  The targets come from the restore packet. Activate later states the expected result, which nvx-rs: the restricted control state and Activate after a restore, in the guest library and the test adapter's framing #843 checks against Repaired.

• No guest randomness before the reseed: repair calls neither getrandom nor /dev/urandom before step 3. A generated machine ID is drawn after Activate (nvx-rs: activate a clone's root for GPT images and either upper, with its export, network settings and workload view #845).

• Deferred time work runs in the supervised time daemon (TimeAbi::start_daemon): the restore checks, the RCU grace period, detector restoration and the faster discipline cadence. It may end after Ready, and its failures stay fatal repair failures.

• Tests, with fakes for the time ABI, sysfs and the reseed: no randomness before the reseed; exactly one acknowledgment, across retries and re-entry; a memory target above the capacity, refused.

PR 3 of 3: failure statuses, and repair in the test adapter's guest. Step 3; needs PR 2.

• Strict mode: the embedded operations return RepairError, with the stage, the cause and the progress, so the adapter owns the exit status and the shutdown. The command tools keep their enforcing behavior.
• The status table: 193, 194 and 195 keep their meanings. Other repair failures, and the activation failures of nvx-rs: the restricted control state and Activate after a restore, in the guest library and the test adapter's framing #843 and nvx-rs: activate a clone's root for GPT images and either upper, with its export, network settings and workload view #845, get distinct documented statuses.
• The test adapter's guest runs repair after a restore, and shuts down with the documented status if it fails.
• Tests: each failure class, with its status; strict errors that never power off. In VMs, with nvx-rs: restore clones from a template through Activate, Ready and Start #844's PR 5, on KVM, MSHV and WHP: memory targets, and deferred time work that ends after Ready.

Not in scope: CPU targets (#849); the machine ID (#845); NVX's init (#852).

Guide (#591's numbering): 5.5.4 (memory activation), 5.5.7 (guest repair, in-process), 5.5.8 (entropy refresh from an in-memory seed), 3.2.10 (the guest's obligations), 5.6.2 (failure classes and statuses).

Done when: the three PRs are merged with their tests, and the test adapter's guest repairs its clones.