Expose authoritative snapshot restore and tiered capture through RPC

Tracking issue: MicroVM support and private snapshot restore.

Motivation

RPC clients need the same validated snapshot lifecycle as local callers. The saved
machine contract must remain authoritative: attachment handles and permitted
restore overrides should not let a client bypass compatibility, tier, memory, or
identity checks by constructing a conflicting machine description.

Proposed Scope

• Expose tiered capture and authoritative restore through the VM service protocol
  and its implementation.
• Define which fields come from the snapshot and which restore-time inputs a
  caller may supply, rejecting conflicts before the VM becomes active.
• Carry filesystem, network, and block attachments through the appropriate RPC
  representation, including file-descriptor ownership where applicable.
• Apply the same generation, guest-readiness, VP-target, memory, and tier policies
  as the underlying capture/restore transaction.
• Define completion, errors, cancellation, and cleanup across the service boundary.
• Keep protocol changes, attachment-handle handling, documentation, and snapshot
  VMM coverage in one PR.

Acceptance Criteria

• An RPC client captures each supported tier and restores a guest through the
  authoritative snapshot path without reconstructing an independent machine model.
• Conflicting configuration, unsupported overrides, and invalid attachments
  fail before device activation or VP execution.
• Attachment descriptors/handles have explicit ownership on success, failure,
  and cancellation, with tests for missing, duplicate, and invalid inputs.
• RPC completion reflects the documented publication or guest-readiness
  boundary, rather than only acknowledging that work was queued.
• Failed or cancelled requests do not leak descriptors, staging artifacts,
  mappings, or partially active VMs.
• VMM tests exercise RPC capture/restore with supported console, network,
  filesystem, block, and restore-override configurations.
• Protocol documentation explains compatibility, tier selection, override
  limits, and client-visible failure behavior.

Dependencies

• E06: Lazy WHP GPA registration precedes
  this final integration step in review order; lazy mode remains optional.
• E04: Clone/resume capture tiers and
  E05: Restore-memory targets supply the
  functional policies exposed by the service.

Non-Goals

This issue does not introduce a second snapshot engine, let RPC input override the
saved machine contract arbitrarily, or change existing cold-boot RPC defaults.

Start with the VM service protocol and its implementation, then read the linked E04 and E05 issues for the capture tiers and restore-memory policies. Use the VMM test coverage and protocol documentation as the completion targets: RPC capture and restore must preserve authoritative snapshot checks, attachment ownership, documented completion behavior, and cleanup on failure or cancellation.