[Sn0wyDay]

Problem

On 32-bit builds, JavaScript-controlled lengths can wrap an element-count multiplication before the allocator sees the request. For example, Reflect.ownKeys(new Proxy({}, { ownKeys() { return { length: 0x20000000, 0: "x" }; } })) and Array.prototype.toReversed.call({ length: 0x20000000 }) each reach an 8 * length allocation that wraps to zero. The following element write can corrupt memory. The allocator-size guard in #556 cannot detect a size that has already wrapped.

Change

• Check element counts against the largest safe allocation size before multiplication in fast arrays, property enumeration, and typed-array sort.
• Build a Proxy ownKeys table as entries are validated, so a fake huge length does not allocate in advance and error cleanup only frees initialized atoms.
• Add a memory-limited JavaScript regression test for the crafted lengths, cleanup, and normal table growth.

This addresses the JavaScript paths described in #535 and complements the C allocator API fix in #556.

Validation

• make -j8 test on macOS arm64
• make clean && make CONFIG_ASAN=y CONFIG_UBSAN=y -j8 test on macOS arm64
• Isolated 32-bit arithmetic simulation confirmed that the two JavaScript calls reach a zero-byte allocation and an out-of-bounds first write before this change. A native 32-bit run has not yet been completed.