fix/perf: migrate clone restores to --restore-mode and use mmap for Linux fan-out

[CMGS]

Problem

vk-cocoon still models lazy restore as CloneOptions.OnDemand and emits the removed cocoon vm clone --on-demand flag in buildCloneArgs. Current argv tests still require the old flag.

It is selected for every non-Windows Cloud Hypervisor clone path:

• from-dir, fork, and normal clone: provider/cocoon/create.go
• hibernation restore: provider/cocoon/update.go
• OS policy: useOnDemandClone

cocoon removed --on-demand in cocoon#127. Current cocoon accepts only --restore-mode copy|ondemand|mmap. This is a compatibility failure for current Linux/CH clone paths, not only a performance opportunity.

The mmap implementation in cloud-hypervisor#1 measured a 16-way, 512 MiB clone burst at 443–463 ms to 72–82 ms per-clone p50, with wall time falling from 456–478 ms to 87–108 ms.

Proposed scope

• Replace CloneOptions.OnDemand bool with an explicit restore mode.
• Emit --restore-mode <mode> for Cloud Hypervisor and no restore-mode flag for Firecracker.
• Keep the policy in one helper:
  • Linux CH: mmap when using the supported and pinned cocoonstack CH build.
  • Windows CH: copy until mmap is validated against Windows boot and DHCP behavior.
  • Firecracker: omit the option.
• If unpinned third-party CH builds are supported, provide one deployment-level override and retain copy as the compatibility default.
• Update stale argv tests and deployment documentation.

mmap requires the snapshot memory file to remain present and unchanged for the VM lifetime. Current cocoon direct clone hardlinks memory files into the VM run directory.

Acceptance criteria

• No vk-cocoon path emits --on-demand.
• Table tests cover copy, ondemand, and mmap on CH and verify that FC emits none of them.
• Normal clone, fork, from-dir clone, and hibernation restore work against current cocoon.
• The supported deployment pins or documents the CH build required for mmap.
• Linux smoke tests cover mmap clone and restore; Windows remains on copy and passes boot/DHCP readiness.
• A 1/8/16-way comparison records create-to-running p50/p95 and confirms mmap improves fan-out latency over copy on a compatible host.

[CMGS]

Code merged in #36 (main a3361dd). Status against acceptance criteria:

Met (software):

• ✅ No vk-cocoon path emits --on-demand (git grep -- '--on-demand' -- '*.go' → zero).
• ✅ Table tests cover copy/ondemand/mmap on CH and assert FC emits none (vm/cocoon_cli_test.go TestBuildCloneArgs + TestParseRestoreMode).
• ✅ Deployment documents the CH build required for mmap (docs/configuration.md VK_RESTORE_MODE row: mmap needs a CH build with mmap restore support; opt-in, default ondemand; Windows forced to copy).
• ✅ argv contract cross-checked against current cocoon source (cmd/vm/commands.go, cmd/core/vmconfig.go restoreModeFromFlags) and upstream cloud-hypervisor MemoryRestoreMode — matches.

Pending (hardware, not yet run):

• ⬜ Normal / fork / from-dir clone and hibernation restore exercised against a live current-cocoon binary.
• ⬜ Linux smoke: mmap clone + restore; Windows stays copy and passes boot/DHCP readiness.
• ⬜ 1/8/16-way create-to-running p50/p95, mmap vs copy, on an mmap-capable host.

CI runs lint (dual-platform) + go test -race only — it never invokes a real cocoon vm clone, so the argv and the mmap win are unverified on hardware. Keeping open until the testbed run lands.