perf: inline getArg(source) in generatedPositionFor

[7rulnik]

Summary

Follow-up to #72: generatedPositionFor still reads source through util.getArg even after #72 inlined line / column. Same megamorphic-call-site exposure — and same magnitude of payoff once inlined.

source can legitimately be null (sources arrays accept null entries), so the typeof !== 'number' validation from #72 doesn't fit. Behavior is preserved by deferring the "is a required argument" throw to the slow path: _findSourceIndex runs first; only if its lookup fails AND the key is absent from aArgs does the throw fire. Defined values (the hot path) take a single property access and never see the in check.

Results (bench-diff vs main, SOLO)

babel.min.js.map (2 runs, full-phase third run for sanity)

phase	run 1	run 2
Generated Positions speed	+23.3%	+21.8%
Generated Positions init	+0.3%	+0.1%

Full-phase run also showed Trace speed (random) at +11.9% as a positive halo (V8 IC sharing across opf/gpf paths).

vscode.map (5 runs)

run	Δ
1	+2.1%
2	−4.6%
3	+1.0%
4	+0.6%
5	+13.4%

Median +1.0%, mean +2.5% — within noise. (An earlier draft that did the 'source' in aArgs check on the hot path regressed vscode by a reproducible 5–16%; moving the check to the slow path eliminated that.)

Behavior

Throw on missing source key is preserved: gpf({line: 1, column: 0}) still throws Error('"source" is a required argument.'). The throw is just delayed until after the slab lookup, which is fine because the lookup is cheap and the throw is fatal anyway.

Test plan

• yarn test — 205/205 non-TODO tests pass
• Two babel runs reproduce the +22% win on Generated Positions speed
• Five vscode runs confirm no regression after moving the in check to the slow path