Bug 260069

In OSAllocatorWin, if you call OSAllocator::protect with readable false and writeable false, it’ll free the page + decommit. To the caller, this looks like it does the right thing - attempting to access the freed page will throw an access violation. However freeing the page there’s a risk that we re-allocate that page.

For WasmMemory we want the pages to remain reserved in the virtual address space, so if someone tries to access memory in a “red zone” page it’ll throw an access violation. If that page is re-allocated, we could overflow WasmMemory and read / write that page.

OSAllocatorPOSIX always calls mprotect so does not have the same problem.