fix(index): serialize FTS position prewarm to avoid an IO-scheduler deadlock

[BubbleCal]

Problem

prewarm_index(..., with_position=True) deadlocks on position-bearing inverted indexes: all tokio workers park and the prewarm never completes (reproduced on a 50M-doc index; >14 min with zero progress before this fix, vs ~19 min to fully prewarm 162G after it).

Position streams are dominated by a few huge hot-token rows, so prewarm chunks sized for the 128MB average routinely span hundreds of MBs to GBs. Two or more such read_ranges in flight on the store's shared ScanScheduler can exhaust its byte backpressure window while every request still has undelivered pages: a request's later pages never pass the min_in_flight priority bypass, so nothing can complete and nothing frees the window.

Fix

A single request in flight always delivers in order and recycles the window, so position prewarm now runs its chunks serially. Position-less prewarm keeps the concurrent path (its chunks are bounded by the 128MB target and never wedge).

The scheduler-side wedge (concurrent large read_ranges on one ScanScheduler) is a separate latent lance-io issue; this change removes the only known trigger.

Verification

• Repro before/after on a 50M-doc 162G positions index: with_position prewarm hung (>840s timeout) → completes in ~19 min; position-less prewarm unchanged (~30s).
• cargo test -p lance-index (inverted suite), cargo clippy -- -D warnings, cargo fmt --check all clean.

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!