[cctest][wasm] Fix JumpTablePatchingStress on systems with 64k pages

This test allocates a large mapping and splits into kThunkBufferSize
areas that it needs to be able to change permissions on. So
kThunkBufferSize needs to be set to the largest page size possible,
which is 64k at the moment.

It doesn't matter if kThunkBufferSize is larger than the actual page
size.

Bug: v8:10808
Change-Id: I3a8947f04a7ec25be49a54015cd128e901065ea6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2463404Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#70449}

test/cctest/wasm/test-jump-table-assembler.cc

@@ -33,13 +33,9 @@ constexpr int kJumpTableSlotCount = 128;
 constexpr uint32_t kJumpTableSize =
     JumpTableAssembler::SizeForNumberOfSlots(kJumpTableSlotCount);
 
-// Must be a safe commit page size.
-#if V8_OS_MACOSX && V8_HOST_ARCH_ARM64
-// See kAppleArmPageSize in platform-posix.cc.
-constexpr size_t kThunkBufferSize = 1 << 14;
-#else
-constexpr size_t kThunkBufferSize = 4 * KB;
-#endif
+// This must be a safe commit page size so we pick the largest OS page size that
+// V8 is known to support. Arm64 linux can support up to 64k at runtime.
+constexpr size_t kThunkBufferSize = 64 * KB;
 
 #if V8_TARGET_ARCH_ARM64 || V8_TARGET_ARCH_X64
 // We need the branches (from CompileJumpTableThunk) to be within near-call