Fix fork reset mmap source

[perbu]

I ran into an issue with Python 3.14. First attempt at a fix had some potential performance on a throw, that is addressed in the second commit.

The reset_keep_all_work_memory=true fast recycle path in vMemory::fork_reset
restores each dirty bank page with:

page_duplicate((uint64_t*)our_page,
    (const uint64_t*)main_vm.main_memory().safely_at(addr, page_size));

safely_at(virtual_addr) treats the recorded guest-virtual address as a
physical one. That only holds for identity-mapped main memory. Pages backed by
the mmap physical region (MMAP_PHYS_BASE) are not identity-mapped, so for
every recorded page living there the copy sourced an unpopulated main-memory
page — silently writing zeros into the fork's bank page on every reset.

The 2MB-leaf case was doubly wrong: the lambda parameter shadowed the loop
variable, so the copy source was the bank's physical block address rather
than any guest virtual address.

Observed impact

CPython 3.14 places PyInterpreterState on mmap-region pages. A recycled fork
reads interp->obmalloc as NULL on its next turn and faults in obmalloc's
arena_map_get — deterministically, every second call (fresh mint OK →
recycled fork faults → retire/remint repeats). CPython 3.12 survives only
because nothing it reads back post-reset happens to live on mmap-backed pages;
the copy-back corrupts them there too.
page-table walk and from the vCPU (not stale TLB); the master's true page
(PTE → mmap region) holds the pointer while the identity read returns zeros;
and reset_keep_all_work_memory=false makes the failures vanish.

Fix

Commit 1 — resolve each 4K source page through the master's page tables
with readable_page_at, which handles identity-mapped and mmap-backed
physical pages alike and returns the correct 4K segment when the master holds
a 2MB huge page. A 2MB fork leaf is restored one 4K page at a time, covering
masters with either page size underneath. The loop is arch-neutral (the arm64
backend has its own readable_page_at); the PRESENT/VALID flag ifdef follows
the existing pattern in this file.

Commit 2 — readable_page_at throws when the master's entry is unpresent,
and unpresent-but-cloneable entries are real (anonymous memory the master
mapped but never touched). Before this commit, one such recorded page made
every fork_reset throw mid-loop into the full bank-reset fallback — silently
and permanently demoting that fork off the fast recycle path. The master is
frozen after fork, so an entry unpresent at reset time was unpresent at write
time — exactly the unpresent-CoW case in writable_page_at, where a fresh
fork gets a zeroed page (zero_and_update_entry, no DIRTY bit). Catching per
page and page_memzero-ing the destination reproduces fresh-fork semantics
bit-for-bit; the happy path pays nothing and the outer catch remains the last
resort for genuinely unexpected failures.