mongodb/insert_find: 222× Node on instructions and 10× Node peak RSS (1.2 GB); GC is 21% and List push/shift property reads 34%

[proggeramlug]

Found by the package matrix re-run (#11723, at 9e29f59). mongodb/insert_find now runs correctly (it used to hang, #11460), but:

• Instructions: 222× Node, the worst workload in the matrix. Property reads in the driver's List.push/shift take 34% (perf: property access is 13x-112x node warm — two static reads cost 162 instructions against node's 12, and a const-key read costs 7.6x the same read spelled statically #10761, perf: a dynamic string-keyed property read is 5.5x node when the key is present and 23x when absent, while static reads and array indexing both beat node #10753, perf: obj.method() through the runtime dispatcher is ~3,000× slower than Node (two O(own-keys) string-compare scans per call before any cache) #10502). GC takes 21% (minor 12%, major 9%; related to GC nursery pacing (#11645): accepted regressions to recover #11699).
• Peak RSS: 1,185 MB on Linux vs Node's 115 MB, about 10×. Every other workload but one is below Node on RSS.

Profile: benchmarks/packages/profile/rerun-2026-09-30/. To reproduce: scripts/package_bench.py (benchmarks/packages) for the mongodb workloads; they use in-process fake servers.

Acceptance: RSS within 2× Node, and GC under 10% of instructions, with no regression on the other package rows.