fix: avoid u64 overflow in solve_itp for large nmax values

When epsilon is very small (e.g. 1e-24), nmax can exceed 63.
The expression `(1u64 << nmax) as f64` then overflows: debug
builds panic, release builds silently produce the wrong value
because x86 masks the shift amount to 6 bits (so << 64 wraps
to << 0 = 1).

Replace with `(nmax as f64).exp2()` which is mathematically
identical (2^nmax) but uses f64 arithmetic, handling nmax up
to ~1023 before saturating to +inf — well beyond any practical
epsilon.

Add a regression test with epsilon=1e-24 (nmax≈79) that panics
on the original code in debug mode.

Author: greysquirr3l

kurbo/src/common.rs

@@ -710,7 +710,8 @@ pub(crate) fn solve_itp_fallible<E>(
 ) -> Result<(f64, f64), E> {
     let n1_2 = (((b - a) / epsilon).log2().ceil() - 1.0).max(0.0) as usize;
     let nmax = n0 + n1_2;
-    let mut scaled_epsilon = epsilon * (1u64 << nmax) as f64;
+    let powi_nmax = nmax.min(i32::MAX as usize) as i32;
+    let mut scaled_epsilon = epsilon * 2.0_f64.powi(powi_nmax);
     while b - a > 2.0 * epsilon {
         let x1_2 = 0.5 * (a + b);
         let r = scaled_epsilon - 0.5 * (b - a);
@@ -1097,6 +1098,14 @@ mod tests {
         assert!(f(x).abs() < 6e-12);
     }
 
+    #[test]
+    fn test_solve_itp_large_nmax_does_not_overflow() {
+        let f = |x: f64| x - 0.5;
+        let x = solve_itp(f, 0.0, 1.0, 1e-24, 0, 0.2, f(0.0), f(1.0));
+        assert!(x.is_finite());
+        assert!((x - 0.5).abs() <= 1e-12);
+    }
+
     #[test]
     fn test_inv_arclen() {
         use crate::{ParamCurve, ParamCurveArclen};