Allow bounded private-memory expansion during restore

Tracking issue: MicroVM support and private snapshot restore.

Motivation

A reusable snapshot may serve workloads with different memory requirements. Restore
should be able to select a larger supported memory target without modifying the
immutable RAM image or confusing saved contents with newly added capacity. Explicit
bounds and guest-visible policy are necessary to keep that operation predictable.

Proposed Scope

• Distinguish captured RAM, supported expansion capacity, and the requested restore
  target in the machine/snapshot contract.
• Validate the target against layout, alignment, capacity, and host address-space
  limits before committing a restored instance.
• Back the added range privately with defined initial contents, while preserving
  copy-on-write isolation for captured RAM.
• Expose the selected target through the supported guest memory and readiness
  contract; reject guests or layouts that cannot consume the change safely.
• Account for added memory and unwind partially prepared mappings on failure.

Acceptance Criteria

• Restore at the captured size preserves existing behavior, and a valid larger
  target makes the added range available through the documented guest contract.
• Newly added RAM is zero-initialized, private to the instance, and does not
  disclose host data or writes from another restore.
• Requests beyond capacity, misaligned targets, unsupported shrinking, and
  arithmetic overflow are rejected before guest execution.
• Tests verify boundary targets and the distinction between captured bytes,
  available capacity, and committed private backing.
• Allocation or mapping failure releases partial state without modifying the
  snapshot or its block attachments.
• VMM coverage accesses both captured and expanded ranges and verifies
  isolation between independent restores.

Dependencies

• E04: Block roles and clone/resume snapshot tiers.

The private-mapping and guest-readiness contracts established earlier remain the
basis for expansion; this PR should not create alternate versions of them.

Non-Goals

This issue does not provide arbitrary runtime memory hotplug, memory shrinking, or
unbounded overcommit. Lazy WHP GPA registration is separate performance work.

Start with 00-microvm.md and dependency issue E04 (#4445), then trace the existing machine/snapshot, private-mapping, and guest-readiness contracts. Define the restore-target and expansion behavior against the stated bounds and failure cases. Done includes boundary and overflow tests, zeroed private memory, restore isolation, and cleanup after allocation or mapping failure.