Define portable CPU and clock snapshot contracts

Tracking issue: MicroVM support and private snapshot restore.

Motivation

A restored guest must see CPU state and time that agree with the save boundary.
Serializing backend-specific state without an explicit compatibility contract can
admit an incompatible restore target or produce clocks that jump inconsistently
between restored processors. Portability needs defined limits, not an assumption
that every host or hypervisor can consume every snapshot.

Proposed Scope

• Define the CPU state and capability contract captured at the quiesced boundary.
• Separate portable state from backend-specific requirements and validate target
  compatibility before resuming guest execution.
• Capture the guest clock relationship at the save boundary and define how paused
  time is treated during restore.
• Synchronize restored virtual-processor clocks before execution, including the
  MSHV restored-vCPU path where that backend is supported.
• Propagate unsupported-state and clock-restore failures through the fallible
  lifecycle interfaces.
• Keep SMP topology extensions in their own PR rather than adding fields that
  this contract cannot yet use.

Acceptance Criteria

• CPU state round trips preserve the defined architectural state on supported
  save/restore paths.
• An incompatible CPU or backend contract is rejected before any VP resumes.
• Clock tests cover a nonzero pause interval and verify the documented
  continuity and monotonicity behavior.
• Restored VP clocks use a consistent saved boundary; supported MSHV coverage
  explicitly tests clock synchronization before vCPU execution.
• Backend failures return lifecycle errors without partially resumed VPs.
• Documentation records supported host/backend combinations and identifies
  unavailable runtime coverage separately from passing unit tests.

Dependencies

• S01: Fallible lifecycle and quiesce transactions.

Non-Goals

This issue does not promise arbitrary cross-host migration, define SMP topology
expansion, or implement the snapshot manifest and RAM publication transaction.

Start with the linked 00-microvm.md tracking document and the S01 fallible lifecycle and quiesce transaction dependency. Trace the lifecycle interfaces and the MSHV restored-vCPU path, then use the acceptance criteria to define completion: compatible CPU state, synchronized clocks, rejected failures before resume, and documented host/backend coverage.