fix: guard unchecked caller-supplied indices across _no_range kernels

[samukweku]

Summary

• max_rev/max_no_range.rs, min_rev/min_no_range.rs, sum_rev/sum_no_range.rs, and prod_rev/prod_no_range.rs each indexed arr/booleans by index_left, read straight from the caller-supplied left_index array, with no bound check at all. A negative or too-large index_left panicked (pyo3_runtime.PanicException) instead of failing gracefully.
• Guards index_left with checked_index, skipping the row when it doesn't resolve; right_index needs no such guard since it's only ever used as a HashMap key, never to index an array.

Folded in: four more functions with the same shape of gap

Found while auditing for this specific pattern (arr[*x as usize] with no/incomplete guard), not previously filed as separate issues -- folded into this PR rather than filed separately per explicit direction:

• compare/comp_no_range.rs and comp_no_range_ne.rs only guarded the -1 sentinel before indexing right/right_booleans by right_pos, never the upper bound -- a positive out-of-range value fell straight through unchecked. comp_no_range_ne.rs also gains an ensure_equal_lengths check between right and right_booleans, since both are indexed by the same right_pos and need matching lengths for a single checked_index call to safely cover both (matching how arr/booleans are validated together elsewhere in aggs/).
• index_builder::build_positional_index only guarded position < 0, same gap.
• index_builder::reorder_index had no guard at all, not even the -1 sentinel, on two chained reads (starts/counts indexed by val, then result indexed by the pos derived from those reads) -- the most exposed of the four. An adversarial review of the initial sentinel-and-skip fix caught that reorder_index's sole caller (pyjanitor) does an unfiltered right.iloc[reordered_positions] on the result, and pandas treats -1 as the last row, not "no match" -- a malformed mapping would have silently produced a wrong-but-plausible reordered DataFrame instead of an error. reorder_index now returns PyResult and raises ValueError on any unresolvable mapping instead.

Follow-up: remaining index_builder.rs bounds + a length-validation gap

Two more rounds of adversarial review on this same branch turned up further gaps in index_builder.rs beyond the four above:

• index_starts_only/index_ends_only/index_starts_and_ends and their _keep_first/_keep_last variants, plus build_positional_index_first/_last, gained the same checked_end/checked_range-style per-row bound checks as the rest of the crate (issue [BUG] _rev/*_no_range.rs indexes arr/booleans by unchecked left_index/right_index values #38 proper).
• That per-row fix left a separate whole-call gap unaudited: none of those functions validated that starts/ends/counts were the same length before zip-ing them, so a mismatch silently truncated to the shortest array instead of raising -- the same shape of gap ensure_equal_lengths already closes for the sum/min/max/prod families. All five affected functions now call ensure_equal_lengths up front, with regression coverage in aggs::adversarial_bounds_tests::index_builder_starts_ends_functions_reject_mismatched_lengths.

Follow-up: drop per-call allocation in the bounds-checked path

Adding the per-row guards above introduced a Vec<Option<...>> materialization in every one of those nine functions, even on fully valid input (allocate the validated-range Vec, fill it, sum it for the tape-width precheck, then consume it in the processing loop). starts/ends/counts are cheap-to-reiterate ndarray views, so checked_end/checked_range_or_none are now recomputed in each pass instead -- a cheap O(1)-per-row recompute traded for removing an O(n) heap allocation on this hot join/index-build path. The two build_positional_index_* functions have no width precheck at all, so they drop straight to a single pass with no recomputation. Purely an allocation-strategy change; behavior is identical on every guarded input.

Rebased onto main

Rebased onto main to pick up #46 (the bin_search_*_first allocation-strategy work), resolving two AGENTS.md Learned Patterns conflicts (both were independent appends at the same location, plus one genuine duplicate entry from an earlier merge, which was deduplicated).

Performance

Measured checked_index's added cost directly (built the wheel, timed from Python) across 100 / 1M / 10M rows: compare_no_range, build_positional_index, and reorder_index held flat ~0.5-1.4 ns/row across all three sizes -- the guard is genuinely O(1) per element, not a hidden O(n)/O(n^2) cost. max_rev_no_range's per-row cost grows with n (15 ns/row at 1M, 50 ns/row at 10M), but that's pre-existing HashMap-rehashing cost from its dictionary-based grouping as distinct keys grow -- not something this fix introduces, confirmed by the other three (no HashMap involved) staying flat.

Test plan

• cargo test --no-default-features -- 167 passed, 0 failed
• cargo clippy --all-targets --all-features -- -D warnings -- clean
• cargo fmt --check -- clean
• cargo bench --no-default-features --no-run -- compiles
• New regression test (no_range_and_positional_functions_reject_out_of_bounds_indices_without_panicking) exercises all 8 originally-touched functions with out-of-bounds/mismatched input, confirming each now degrades gracefully (skip, sentinel, or ValueError) instead of panicking
• New regression test (index_builder_starts_ends_functions_reject_mismatched_lengths) exercises all 5 starts/ends(/counts) functions with mismatched-length input
• Built the wheel via maturin develop --release and ran the same repros end-to-end plus the tiny/large/very-large timing sweep
• Rebase onto main verified clean/mergeable (gh pr view --json mergeable,mergeStateStatus)

Fixes #38

🤖 Generated with Claude Code

https://claude.ai/code/session_01S1gZKDRiZoBLZnXXXjW3gt