perf: inline getArg(line/column) in originalPositionFor and generatedPositionFor

[7rulnik]

Summary

originalPositionFor and generatedPositionFor still went through util.getArg for the required line / column args (PR #63 only inlined the constructor's optional reads). The profile showed getArg self-time at 2.4% of opf and 2.3% of gpf — but the actual cost was much larger than that: the getArg call site was megamorphic across many call paths in the codebase, blocking V8 from specializing the per-call shape.

This PR inlines the two required reads to direct property accesses. To preserve the documented "is a required argument" error (which getArg threw via its missing-key branch), an explicit typeof !== 'number' guard runs before the existing range check.

Results (bench-diff vs main, SOLO)

babel.min.js.map

phase	run 1	run 2
Trace speed (random)	+1.4%	+2.7%
Trace speed (ascending)	+51.3%	+53.8%
Generated Positions init	−0.1%	−0.5%
Generated Positions speed	+23.2%	+28.7%

Full-phase run also clean: Init / eachMapping all within ±3% noise.

vscode.map

phase	Δ
Trace speed (random)	+10.2%
Trace speed (ascending)	+40.4%
Generated Positions speed	+101.6%

API note

The required-argument error type changes from Error (thrown by util.getArg) → still Error, message format identical. Same throw semantics for missing key and undefined value (slightly tighter than before — previously undefined value silently produced wrong results).

Test plan

• yarn test — 205/205 non-TODO tests pass
• Two independent bench-diff runs on babel show the reproducibility of the +50% / +25% gains
• vscode confirms the pattern scales to large fixtures
• Full-phase babel run shows no regressions outside ±3% noise