fix: reject non-sentinel negative starts in compare_start_end's width precheck

[samukweku]

Summary

compare_start_end_*'s expected_matches_width precheck (in src/compare/comp.rs) filtered candidate rows with **s != -1 && **e != -1 && **s < **e before casting both bounds to usize and subtracting. That only rejects the exact -1 sentinel — any other malformed negative start (e.g. -2) that still satisfies start < end in i64 space (starts=[-2], ends=[1]) slipped through, then underflowed (1usize) - ((-2i64) as usize) before ensure_tape_width ever ran: a panic in debug builds, a silently bogus width in release.

Fix (commit 1): require both bounds to already be non-negative (**s >= 0 && **e >= 0) in the wrapper's precheck instead of only excluding -1.

Adversarial review of the first commit found a second, deeper instance of the same root cause (P1): compare_start_end_core itself — not just the wrapper's precheck — has its own independent row-acceptance check, *start == -1 || *end == -1 || *start >= *end, with the identical gap. starts=[-3], ends=[-2] isn't caught by the wrapper's now-fixed precheck's rejection (it correctly contributes 0 to the width sum), but the wrapper still calls into the core regardless, and the core's own check accepts the row (-3 >= -2 is false), casts both bounds to huge-but-still-ordered usize values, and panics indexing right/matches far out of bounds. Reproduced directly against the core (index 18446744073709551613 is out of bounds for array of shape [1]) before the fix.

Fix (commit 2): the same "require non-negative before cast" fix, applied to the core's own check (*start < 0 || *end == -1 || *start >= *end — only start needs the explicit non-negativity check, since start >= 0 && start < end together prove end > 0 too).

Neither fix changes which rows a well-formed caller's start/end pairs produce — both only tighten rejection of malformed input that was already reachable, just not exercised by any prior test.

Test plan

• cargo test --no-default-features -- 169 passed, 0 failed:
  • non_sentinel_negative_start_does_not_underflow_the_width_precheck -- exercises the wrapper-level fix through the actual compare_start_end_int64 pyfunction via an embedded Python interpreter
  • both_bounds_negative_but_start_less_than_end_contributes_nothing_not_a_panic -- exercises the core-level fix directly against compare_start_end_core with the review's exact counterexample (starts=[-3], ends=[-2]), confirmed to panic before the fix and pass cleanly after
• cargo clippy --all-targets --all-features -- -D warnings -- clean
• cargo fmt --check -- clean
• Built the wheel via maturin develop --release and ran the review's exact counterexample end-to-end through compare_start_end_int64 in Python: returns ([0], [0], 0) cleanly instead of panicking