mpk: restore protection keys after mmap'ing memory images

[jlb6740]

A fresh mmap associates the pages it replaces with the default protection key 0, and key 0 is accessible from every stripe (host code needs it). MemoryImageSlot maps over pkey-colored pool slots in three places, so any module with a (data ...) segment silently lost its key. Because MPK striping deliberately shrinks the guard regions between slots, a neighboring instance could then read and write that memory for real. Note that mprotect preserves the key, so only mmap sites are affected.

Fix this by re-applying the key with pkey_mprotect after each mmap: add ProtectionKey::reprotect, give MemoryImageSlot the key its stripe was colored with, and call the new reapply_pkey helper after map_at, remap_as_zeros_at, and erase_existing_mapping.

Tables, stacks, and GC heaps are never pkey-colored, and decommit uses madvise(MADV_DONTNEED) which preserves VMA flags, so MemoryImageSlot was the only exposure.

Cost: one extra syscall per mmap, and instantiate only mmaps when a slot is handed a different image than it already holds. Measured over 1000 instantiations, a module repeatedly instantiated into its affine slot adds 8 calls total (one per slot, at first use) and is in the noise end-to-end. A pool thrashing between more modules than it has slots takes 2 extra calls per instantiation, ~+43% on instantiation. With MPK disabled ProtectionKey is uninhabited and this all compiles away.

Fixes #13982
Fixes #7942