perf: inline GLB binary search in generatedPositionFor cold path

[7rulnik]

Summary

When generatedPositionFor misses the per-source warm cache and bias is GLB (the default), it falls through to _findMapping → binarySearch.search → iterativeSearch → compareByOriginalPositions. Profiling against babel.min.js.map showed iterativeSearch at 64% self-time for random gpf probes — driven by the indirect aCompare callback at every step and the per-call {source, originalLine, originalColumn} needle allocation.

This PR inlines a GLB binary search with direct field access on mappings[mid] for the GLB cold path. The structure mirrors what generatedPositionFor already uses inside its cache-hit branch (source-map-consumer.js:1088-1112). LUB queries still go through _findMapping unchanged.

Results

bench-diff vs main, SOLO, scoped to genpos phases:

fixture	Generated Positions speed	init
babel.min.js.map	6.63M → 15.14M ops/sec (+128%)	flat (within ±2%)
issue-41.js.map	1.95M → 5.45M ops/sec (+180%)	flat (within ±2%)

CPU profile after the change confirms iterativeSearch is no longer in the top frames for the gpf scenario.

Test plan

• yarn test — 205/205 non-TODO tests pass; the 8 failures are pre-existing # TODO items unrelated to this change
• bench-diff.sh main trace — full phase set on babel: only Generated Positions speed shifts; everything else within noise
• CPU profile re-run on the gpf scenario confirms the hot frame is gone