perf(rowids): probe the fragments instead of merging every row id

[pengw0048]

Problem

RowIdIndex::new reads every row id of every fragment whose sequence is not a
plain Range. decompose_sequence has a constant-time path for
U64Segment::Range without deletions; every other encoding, and every fragment
that carries a deletion file, materializes one (row_id, address) pair per row,
sorts them, and re-encodes two segments. get_row_id_index builds the index for
the whole dataset, so a lookup of one row id pays for the whole table.

A delete puts a table on that path and keeps it there. While the deletion files
exist, the build checks the deletion vector row by row. After a compaction
materializes those deletions, the ids inside each fragment are no longer
contiguous, so the build decodes and re-encodes every row id instead.

The cost repeats: the index weighs about as much as the sequences it copies, so
on a large table it does not fit DEFAULT_METADATA_CACHE_SIZE, and the next
lookup builds it again.

Change

new picks one of two representations and never changes it.

• The merged map is what it builds today, and it stays the default: a
  Range-only sequence decomposes in constant time, and a small table is cheap
  to read whatever its encoding.
• A probe answers from one entry per fragment — the Arc<RowIdSequence>,
  the deletion vector, and each segment's row id range plus its physical start
  offset. new reads those bounds instead of every row id. A lookup binary-
  searches the fragments by their lowest row id, descends a max-end heap so a
  fragment out of reach of the id costs nothing, and asks the covering segment
  for position.

new probes only when both hold: the merged build would read more than
MERGE_ROWS_BUDGET row ids, and no more than MAX_PROBE_DEPTH fragments cover
any one id. So wherever the merged map reads faster, it is also the one new
builds.

An unsorted U64Segment::Array gets a sorted lookup table, built with the entry
and charged with it, because its own position scans. build_chunk_from_pairs
sorts its pairs for the same reason, which makes a merged chunk searchable too.

Measurements

Release build, 96-core Linux x86-64. build is RowIdIndex::new; the lookup
columns are 100,000 random live ids.

shape	build	get	get_many
1,000 fragments, 20M sparse ids, 2 fragments per id	0.22 ms vs 485 ms	236 ns vs 23 µs	175 ns vs 24 µs
4,000 fragments, 4M ids, every fragment covers every id	104.7 ms vs 101.5 ms	14 ns vs 13 ns	21 ns vs 18 ns
1,000 fragments, 20M contiguous ids, disjoint	0.23 ms vs 0.19 ms	36 ns vs 36 ns	16 ns vs 14 ns
1 fragment, 2M descending ids (unsorted Array)	7.6 ms vs 8.9 ms	203 ns vs 2 ms	55 ns vs 2 ms

Row 1 is the shape a compacted table has, and the merged map is slower to build
and slower to read there: merging the overlap produces one wide sparse segment
whose position counts bits up to the offset.

Row 2 is where the merged map earns its build, and new builds it, so both
columns match.

Row 4 is the finding about unsorted arrays, in both representations.

On a real table

A dataset of 15,431,187,521 rows in 17,601 fragments, holding 3.36 GB of row id
sequences. Half of the segments are RangeWithBitmap or RangeWithHoles, which
is what a compaction leaves behind once it materializes a long run of deletes.
46 fragments cover the most crowded row id. _take_rows of one column, in a
fresh process:

	before	after
1 row id, first call	~154 s	1.92 s
1 row id, second call	~127 s	1.10 s
200 scattered row ids, first call	161.2 s	9.00 s

(Measured on the earlier revision of this PR; the representation it picks for
this table is the same one, and #8642 takes the 1.10 s to 0.61 s.)

The integrity boundary

new no longer materializes ids on the probe path, so it cannot compare id sets
the way merge_overlapping_chunks does. The check moved to the lookup, where it
is free: a probe already visits every candidate fragment rather than stopping at
the first hit, and a second live match returns the same corrupt-index error the
merged build raises. get and get_many are fallible for this, and every
production caller propagates the error. validate_stable_row_ids remains the
complete offline check.

Checking at construction instead is possible but not cheap on the shape this PR
is for: proving overlapping id sets disjoint without reading them means
intersecting the sequences bit by bit, on the order of 10^10 word operations at
depth 46 over that table's id space, paid again on every process that opens the
dataset. The fallible lookup keeps the boundary without that cost.

Closes #8621

[lance-gatekeeper]

✅ Gate recommendation: approve.

This revision documents the fallible lookup contract with explicit error sections and leaves the verified probe behavior unchanged: both lookup APIs still fail closed when a requested stable ID is live in multiple fragments.

Please mark this PR with the breaking-change label.