perf: inline base64VLQ.decode slow path in _parseMappings

[7rulnik]

Summary

_parseMappings had one call site for base64VLQ.decode — the multi-byte VLQ slow path inside the inner decode loop — but the call site stayed boxed even after PRs #72 / #73 demonstrated that the function-call overhead at hot dispatch sites can be much larger than the profile's self-time share suggests. Inlining the body removes:

• the indirect function call,
• the temp output object's .value / .rest write/read round trip (and the temp = {} allocation at parse start),
• the inner fromVLQSigned call,

so the slow path stays in _parseMappings's frame and V8 can specialize across the call boundary.

The base64DecodeTable (= base64.charToIntMap) is now imported directly in source-map-consumer.js, paralleling the _names._array direct-index pattern from PR #67.

Results (bench-diff vs main, SOLO)

babel.min.js.map (full-phase, single run)

phase	Δ
Init speed, JSON input	+9.0%
Init speed, Object input	+5.8%
Trace speed (random)	+6.3%
Trace speed (ascending)	+2.2%
Generated Positions init	+4.5%
Generated Positions speed	+4.0%
eachMapping speed (generated order)	+4.5%
eachMapping speed (original order)	+3.8%
mean	+4.99%

Three init-only runs reproduce: Init JSON +2.6% / +3.3% / +4.0%, Init Object +0.9% / +1.8% / +1.9%. The full-phase run is higher (+5–9%) likely because of V8 IC sharing — once the parse function is simpler, downstream callers warm up cleaner.

vscode.map (init only, 3 runs)

run	JSON input	Object input
1	+1.9%	0.0%
2	+1.2%	−0.3%
3	+0.1%	−0.7%

Very small / neutral on vscode. babel's win comes from cleaner VLQ distribution; vscode is more memory-bound.

Test plan

• yarn test — 205/205 non-TODO tests pass
• Three babel init runs reproduce the +2-4% init gain
• Full-phase babel run shows positive deltas across all 8 phases (mean +5%) with no regressions
• vscode init runs are neutral (no regression)