perf: stable Mapping hidden class in _parseMappings

[7rulnik]

Summary

Mapping objects built by _parseMappings were allocated via a literal that set source/originalLine/originalColumn/name to null, and were then mutated to overwrite some of those nulls with numbers a few statements later. Each null→number write trips a V8 hidden-class transition, so the resulting mapping objects don't all share the same shape and downstream property reads pay polymorphic-IC costs.

This PR computes every field into a local first and builds the mapping with a single literal. The mapping shape is stable from allocation onward; eachMapping iteration (which reads all six fields per mapping) is the biggest beneficiary.

Results (babel.min.js.map, three full bench-diff runs, medians)

phase	median Δ
eachMapping speed (generated order)	+13.6%
eachMapping speed (original order)	+9.5%
Generated Positions init	+4.9%
Generated Positions speed	+3.5%
Trace speed (ascending)	+0.8%
Trace speed (random)	−0.2%
Init speed, JSON input	−1.0%
Init speed, Object input	−2.0%

vscode.map (scoped phases) shows the same pattern: eachMapping +10%, init −1.5%.

The tradeoff: ~2% slower init in exchange for ~10–15% faster eachMapping and ~3–5% faster generatedPositionFor. For most consumers (bundlers, source-resolvers, error reporters) the per-consumer init cost is paid once and the lookup/iteration cost is paid many times, so the net is clearly positive — but the init delta is real and worth flagging.

Test plan

• yarn test — 205/205 non-TODO tests pass; 8 pre-existing TODO failures unrelated
• bench-diff.sh main trace on babel, three independent runs, eachMapping wins are reproducible (+13.3%, +13.6%, +15.0%)
• bench-diff.sh main trace on vscode.map confirms the same pattern at scale