v0.3.8 — SIMD mappings scan + incremental sort tracking

Performance

This release is a focused performance pass on the hottest path in the library: decoding and encoding the mappings VLQ string. All three changes are internal, with no API changes.

SIMD-accelerated mappings pre-count (srcmap-sourcemap, srcmap-codec)

Both decoders pre-scan the mappings string to count ; and , separators for capacity hints before decoding. That scan was a scalar byte loop LLVM does not vectorize. It's now backed by memchr's SIMD-accelerated count (already in the dependency tree), roughly 7x faster on the scan itself.

• srcmap-sourcemap: the pre-count was ~18% of total VLQ decode time, and decode is ~93% of a parse (the most common operation). from_vlq dropped ~19% on the chartjs fixture.
• srcmap-codec: the pre-count was ~26% of decode() on a 50K-segment synthetic fixture; decode() is ~22% faster on that input.

Incremental sort-order tracking (srcmap-generator)

Encoding previously re-scanned the entire mappings array (is_sorted_by_position, O(n)) to decide whether a sort was needed. That's replaced with an O(1) mappings_in_order flag maintained through a single push_mapping choke point, removing one full cold pass per encode on the default path. The removed scan measured at ~15% of to_json on a 100K-mapping map. Out-of-order insertion is still correctly sorted at encode time (covered by a new test).

Full Changelog: v0.3.7...v0.3.8