S2.2 — Motion-check oversampling: resolve the ×0.1 factor in all planners

Superseded 2026-10-08 by S4.3 — Space resolution valid segment count and S4.4 — Motion validator trait and discrete validator (E4, 0.9.0): the ×0.1 factor is removed as part of the motion-validation redesign (ADR-0003). Cancelled, not done.

Intent

All four planners (rrt, rrt_connect, rrt_star, prm) discretize motion validation at dist / (longest_valid_segment_length × 0.1) — 10× finer than the space's own declared valid-segment contract. For Rust consumers this is wasted work; for oxmpl-py / oxmpl-js users each step is an FFI/wasm round-trip, making planners ~10× slower than the contract requires. This amplified the PRM budget starvation behind the S1.4 test failures.

Acceptance criteria

• Decide and document the intended motion-validation resolution semantics: honor the longest_valid_segment_length contract, or keep oversampling deliberately (and why)
• Either remove the × 0.1 factor or make resolution configurable; behavior aligned across all four planners
• Benchmark before/after on oxmpl-py and oxmpl-js (planner throughput with boundary-bound checkers)
• No test regressions; any tests relying on the finer resolution get explicit segment-fraction settings instead of implicit oversampling
• just test-all green

Notes

• This is a semantics change, not a drive-by edit — removing it outright makes collision checking 10× coarser; review against each space's default longest_valid_segment_fraction and the test geometries (forbidden cone 0.78 rad in py SO(3); 1-unit wall in JS compound).
• 10× throughput win for binding users; also reduces CI wall-clock sensitivity (see S2.1).