perf: replace the recursive decoder with an iterative frame-stack decoder

[mcollina]

This replaces the recursive decoder with an iterative, frame-stack one and builds map results directly instead of through an intermediate pairs array.

Motivation

Profiling showed the recursive tryDecode was paying a per-level function-call cost on nested data, and that building map results via a pairs array plus an all-string scan added allocation and a linear scan per map. This rewrite targets both.

Approach

• tryDecode now decodes a single value using an explicit frame stack instead of recursion, so deeply nested collections no longer grow the call stack and there is no per-value dispatch/return overhead.
• Scalar helpers (decodeSigned, decodeExt, decodeUnsignedInt, decodeFloat) now return the value directly instead of writing to a shared context.value slot.
• Map frames build the result directly as keys and values are fed: string keys land on the plain object with __proto__ deferred to protoValues, and the first non-string key converts the accumulated object to a Map. This preserves preferMap/protoAction semantics exactly while removing the pairs-array allocation and the all-string scan.
• The frame stack is allocated lazily on the first container frame, so decoding a bare scalar (common in the streaming path, which calls tryDecode once per scalar) no longer allocates an empty array.

decodeArray/decodeMap are removed; buildMap remains for the streaming path and empty maps.

Correctness

The full suite (4391 tests) passes on Node 22, 24 and 26, plus 6k randomized round-trips covering Map keys, preferMap, protoAction and mixed string/non-string keys decode byte-identically to the previous recursive decoder.

Benchmark (vs master)

On this machine (interleaved A/B, median of per-outer ratios):

• sample-large decode: +3–5%
• mixed.json (primitive/map-heavy) decode: +6–9%
• encode: unchanged
• streaming decoder(): ~-2% (the iterative scalar path in streaming is a touch costlier; the streaming map path still uses buildMap and is a separate opportunity)

As before, decode remains dominated by native UTF-8 work, so this is a modest but real improvement rather than another step-change.