Track deterministic macOS VM reclaim after native overcommit

[kaaanata]

Goal: give each ephemeral macOS CI job a 16 GiB ceiling while safely oversubscribing aggregate host memory.

Resolved production path:

• Keep checksum-pinned upstream Tart 2.35.0.
• On hosts with at least 64 GiB, configure each of the existing two ephemeral Tahoe/Xcode VMs with 16 GiB; smaller hosts retain 8 GiB.
• Use Virtualization.framework's native demand-backed guest RAM. macOS compression and paging own the actual resident working sets.

Terminal proof:

• Two ordinary 40 GiB guests ran concurrently on the 64 GiB McIntosh host, for an 80 GiB aggregate configured maximum.
• Both reported the full 40 GiB, retained authenticated SSH, and concurrently booted and deleted an iPhone 17 Pro Simulator with Xcode 26.5.
• At completion the host compressor held about 23.44 GiB. Swap remained 12.19 MiB and the cumulative swapout count did not advance.
• Cleanup left only the pinned OCI source image.

Rejected alternatives:

• The macOS traditional Virtio balloon has a 4 KiB PFN versus 16 KiB guest-page accounting failure. A 15 GiB target on a 16 GiB guest wired about 4.25 GiB, a 12 GiB target killed SSH, online deflate failed, and the VZ helper's physical footprint did not fall.
• Private _memoryOvercommitmentAllowed raised configuration validation but caused both a 66 GiB VM and an otherwise-valid 40 GiB VM to fail at start. It is not used.

The issue remains open only as an upstream research tracker for deterministic per-VM reclaim. Production aggregate soft overcommit is complete and does not depend on that future capability.

Canonical evidence: https://git.f.cv/intelligence/monorepo/-/merge_requests/7316