fix: bitmap iterator exhaustion in mask_to_offset_ranges

[wkalt]

In mask_to_offset_ranges, the RangeWithBitmap case advanced the bitmap iterator using a global offset (addr - range.start + offset_start) instead of a range-local position (addr - range.start). When a RangeWithBitmap segment appeared after other segments (offset_start > 0), the iterator was advanced past its end, causing a panic.

The fix separates range-local iteration from the final offset calculation: iterate the bitmap using position_in_range, then add offset_start at the end.

Includes an integration test that reproduces the panic through the user-facing API: write 2 fragments with stable row IDs, delete some rows, compact, create a BTree index, then run a filtered scan.

[github-actions]

Review

Clean, correct fix. No P0/P1 issues.

The bitmap in RangeWithBitmap is indexed by position within the range (0 to range.len()-1), so using addr - range.start + offset_start to advance the iterator was wrong whenever offset_start > 0 — it would seek past the bitmap's end and panic on .unwrap(). The fix properly separates range-local iteration (position_in_range) from the global offset calculation (offset_start + position_in_range - holes_passed), consistent with how RangeWithHoles handles the analogous logic.

Test coverage is good — the integration test reproduces the exact multi-segment scenario through the public API.

LGTM.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[Xuanwo]

Thank you for working on this!