jstests/sharding/query/javascript_heap_limit.js fails on the rhel8-debug-aubsan-classic-engine variant. An aggregation using a $function that allocates a large array is expected to OOM under a 10MB per-query JS heap limit, but instead succeeds, causing assert.commandFailedWithCode to throw "command worked when it should have failed".

Root cause.
This is test calibration drift, not a server regression in behavior. After the MozJS ESR140.11 upgrade (SERVER-126162) and the new mmap-based JS heap accounting (SERVER-126049), the test's allocation of new Array(1000000).fill(0) (~8MB of tracked JS heap) no longer crosses the
10MB per-query limit. As a result no OOM is signaled and the aggregate succeeds.

This test is tagged mozjs_wasm_unsupported, so it only exercises the classic MozJS engine, which enforces JS heap limits by byte-counting in src/mongo/scripting/mozjs/shell/jscustomallocator.cpp. Large GC allocations are tracked via record_mmap_alloc (counted under non-legacy tracking, ignored under legacy tracking).

Proposed fix. Increase the allocation in allocateLargeString() from 1000000 to 4000000 elements (~32MB of tracked JS heap). This restores all of the test's invariants: * Non-legacy tracking @ 10MB limit -> comfortably exceeds 10MB -> OOMs as expected.

• 100MB sufficient limit (and mapReduce, which only obeys the global limit) -> stays under 100MB -> succeeds.
• Legacy tracking -> the large GC buffer is mmap-backed and not counted -> still succeeds, preserving the "legacy doesn't count large buffers" assertion.