fix(intervals): clip sub-query interval starts in both kernels (#242)

[d-laub]

Summary

Fixes #242. intervals_to_tracks (the base-pair track-painting kernel, with numba and rust backends) produced silently-wrong output (numba) or panicked (rust) on datasets with tracks + max_jitter>0.

Root cause: intervals are clipped once at write to a fixed jitter-expanded window, but the read window slides per-read, so an interval's start can fall before the per-read query_start. Both kernels assumed itv.start >= query_start — numba wrapped the resulting negative index (silent wrong output); rust hit a debug_assert/bounds panic.

Fix: clip each interval to the query window in both backends — s = max(start, 0), e = min(end, length), paint only when e > s — preserving the sorted-by-start break. This is the complete, jitter-preserving fix; the right edge was already correct. No write-path, read-path coordinate, or public-API changes.

Changes

• fix(intervals) — clip sub-query starts in both numba (_dataset/_intervals.py) and rust (src/intervals.rs) kernels; cross-backend oracle tests + rust unit tests
• test(parity) — widen the hypothesis parity strategy to generate first-interval starts below query_start, exercising the previously-impossible regime; numba↔rust parity holds
• docs(roadmap) — record the contract fix in the rust migration roadmap
• docs(intervals) — sync the rust module doc-comment with the new left-clamp

Verification

• Full tree green: 847 passed / 21 skipped / 4 xfailed (pytest) + 20 rust tests (cargo)
• The four issue-named end-to-end tests now pass (test_haplotypes_plus_tracks_exact, test_reference_plus_tracks_exact, test_end_to_end_set_insertion_fill, test_dummy_dataset_with_default_insertion_fill_does_not_crash)
• Both backends byte-identical across all input regimes (start<0, end<0, end>length, start>=length, empty slice)
• ruff format/check + pyrefly clean

🤖 Generated with Claude Code