Heuristic-based scratch zeroing strategy for snapshot restore

`HostSharedMemory::zero_or_replace()` currently uses a compile-time `#[cfg(target_os = "windows")]` check to decide whether to zero scratch in-place or replace it with a fresh demand-zero allocation. This works for the immediate problem (large scratch regions on WHP), but the real decision depends on the hypervisor and the size of the region, not just the platform.

There is a break-even point between zero-in-place (via `MADV_DONTNEED` or `fill(0)`) and delete+recreate (fresh `ExclusiveSharedMemory::new`) that varies by:
- Hypervisor (KVM, MSHV, WHP)
- Scratch region size
- Whether `MADV_DONTNEED` is available (KVM-only builds vs KVM+mshv3)

We should benchmark across these configurations and replace the compile-time platform check with a size-based heuristic. This would also allow MSHV builds on Linux to benefit from the fresh-allocation path for large scratch regions.

Ref: #1765

Start with HostSharedMemory::zero_or_replace() and read the context in #1765. Benchmark zero-in-place versus delete-and-recreate across KVM, MSHV, and WHP, varying scratch-region sizes and MADV_DONTNEED availability. Done means the compile-time Windows check is replaced by a size-based heuristic that also benefits large scratch regions in MSHV Linux builds.

Written by the indexing model from the issue text.