Add benchmark lanes for for-in over arrays, holey-array traversal and large-chunk string concat

[lahma]

Coverage lanes ahead of a performance campaign sourced from studying quickjs-ng internals. No engine changes — these lanes give the upcoming PRs their before/after baselines.

New lanes

• ForInGuardBenchmark — array receivers for for-in: dense (1,000 ints), holey (every 4th index present) and an array carrying extra named own props. for-in over an array currently materializes the full key list (List<JsValue> + a JsString per index + numeric sort) on every enumeration — ~1.6–2.5 MB allocated per op on these lanes.
• ArrayHoleTraversalBenchmark — index-loop sum, join, indexOf and the in operator over a 75%-holey (still dense-backed) array vs its packed twin. Each hole read leaves the dense fast path and probes the prototype chain: the holey sum lane allocates ~7 MB per op vs 1.4 KB for the packed twin.
• StringConcatLargeBenchmark — += with 4 KB chunks, 64 KB + 64 KB concatenation, and build-then-charCodeAt-scan, next to the small-chunk baseline that the current ConcatenatedString already handles well. Input for a GO/NO-GO on a rope-style representation for large pieces.

Campaign context

A study of quickjs-ng confirmed most of its playbook is already in place here (shapes, per-node inline caches — which quickjs-ng notably removed again for lack of a JIT to consume type feedback — slot-resolved locals, int arithmetic lanes, sliced/concatenated strings, lazy built-ins). The confirmed gaps these lanes cover:

1. for-in over arrays — QuickJS enumerates 0..count-1 lazily with no key array (build_for_in_iterator fast path).
2. Hole reads / HasProperty probes — QuickJS guards its whole array fast path with a single "clean array prototypes" invariant flag (std_array_prototype).
3. Large-piece string concatenation — quickjs-ng added rope strings for O(1) large concat.

Follow-up PRs will address these one at a time, each gated on these lanes.

🤖 Generated with Claude Code