feat(whp): copy-on-write file mapping for snapshot load

[danbugs]

Summary

Stacked follow-up to #1373. The Windows path in ReadonlySharedMemory::from_file_windows is currently created with PAGE_READONLY + FILE_MAP_READ. That matches the type name (ReadonlySharedMemory) but not the semantics the from_snapshot caller needs: the host-side view has to be writable so WHP (and MSHV) can service the copy-on-write faults the guest takes on first write. A read-only mapping triggers an access violation on the host thread the moment the guest touches any page.

Switch to PAGE_WRITECOPY + FILE_MAP_COPY — the Windows equivalent of Linux's mmap(MAP_PRIVATE) that the Linux from_file path already uses. Reads still come from the backing file; writes transparently allocate private copy-on-write pages.

Relationship to #1373

• Depends on Persist snapshot to disk #1373 landing first — this branch targets disk_snapshot's tip, so the diff here will reduce to just the CoW change once Persist snapshot to disk #1373 is merged.
• Until then, GitHub will show both Persist snapshot to disk #1373's commits and this one. Please review only the shared_mem.rs delta.

Tested

On a Windows box with WHP enabled: Snapshot::to_file then MultiUseSandbox::from_snapshot → restore → call completes cleanly. Pre-fix, the same flow took an access violation on the first page fault the guest triggered after restore.

Known follow-ups (not in this PR)

None for this change specifically. Separate PR will add Registerable for MultiUseSandbox so host functions can be wired on sandboxes acquired via from_snapshot.

[syntactically]

The Windows path in ReadonlySharedMemory::from_file_windows is currently created with PAGE_READONLY + FILE_MAP_READ. That matches the type name (ReadonlySharedMemory) but not the semantics the from_snapshot caller needs: the host-side view has to be writable so WHP (and MSHV) can service the copy-on-write faults the guest takes on first write. A read-only mapping triggers an access violation on the host thread the moment the guest touches any page.

I didn't actually review any of the code in this PR yet, but I want to ask for some clarification from this line in the description. With FILE_MAP_COPY, the CoW will happen for the whole process when the host/guest writes into a page in the region, but that would mean the modification would be visible across all the sandboxes using the same ReadonlySharedMemory as their snapshot. So, it is important that this never happen.

The reason for the PROT_WRITE on Linux is a basically a bug in the MSHV kernel driver, where, at the time of mapping the memory into the guest, even if the mapping is marked readonly and can never actually generate a write, the driver acts as though it was writing to every page in the mapping (without actually changing the contents of any page). Is this PR saying that an analogous bug exists in the WHP/windows kernel mshv root partition driver, and so there are some "fake" write faults that we need to make sure do not trap even though no writes ever actually happen, or is it saying that there are actual writes? The language "so WHP can service the copy-on-write faults the guest takes on first write" imply the latter, which I think would be a problem.