refactor: unify determinant computation pipeline

[acgetchell]

Summary

Unify det_exact, det_exact_f64, and det_sign_exact to share a single internal determinant computation, avoiding redundant work when multiple methods are called on the same matrix.

Current State

Each public method independently calls bareiss_det:

• det_exact → bareiss_det → BigRational
• det_exact_f64 → det_exact → bareiss_det → BigRational → f64
• det_sign_exact → fast filter, then bareiss_det → sign

If user code calls both det_exact() and det_sign_exact() on the same matrix, Bareiss runs twice.

Proposed Changes

Introduce an internal determinant result type:

enum DetResult {
    F64(f64),         // resolved by fast filter (sign is known)
    Exact(BigRational), // computed by Bareiss
}

Add a single internal method:

fn compute_det_internal(&self) -> Result<DetResult, LaError> {
    validate_finite(self)?;

    // Stage 1: f64 fast filter for D ≤ 4
    if let (Some(det_f64), Some(err)) = (self.det_direct(), self.det_errbound()) {
        if det_f64.is_finite() && det_f64.abs() > err {
            return Ok(DetResult::F64(det_f64));
        }
    }

    // Stage 2: exact Bareiss
    Ok(DetResult::Exact(bareiss_det(self)))
}

Then each public method delegates:

• det_exact → always runs Bareiss (needs exact value)
• det_exact_f64 → delegates to det_exact
• det_sign_exact → uses compute_det_internal, extracts sign from either variant

Benefits

• No redundant Bareiss computation in multi-method usage
• Cleaner internal API for future extensions (e.g., caching)
• Aligns with the "guarantee ladder" concept: sign → f64 → exact

Implementation Notes

• Pure internal refactor — no public API changes
• det_exact still needs the full BigRational, so it cannot benefit from the fast filter shortcut (it always needs the value, not just the sign)
• det_exact_f64 could potentially return the fast-filter f64 directly if the filter succeeds (accuracy acceptable for well-conditioned cases), but this changes semantics — defer to a separate decision
• Related: perf: stack-backed storage for exact arithmetic kernels #62, perf: custom f64 → BigRational conversion via mantissa/exponent decomposition #63, perf: integer-only Bareiss determinant (BigInt path) #64 (all improve the Bareiss path this refactor wraps)

[acgetchell]

Analysis after #64 (integer-only Bareiss)

The architecture has changed significantly since this issue was filed. With the bareiss_det_int refactor from #64, the determinant pipeline is already unified around a shared core:

• det_exact → bareiss_det → bareiss_det_int + bigint_exp_to_bigrational
• det_exact_f64 → det_exact (delegates, no duplication)
• det_sign_exact → fast filter → bareiss_det_int → det_int.sign() (no BigRational constructed)

Why DetResult is no longer appropriate

The proposed DetResult enum wrapping BigRational would be a regression for det_sign_exact, which now avoids BigRational entirely (source of the 40x speedup). The paths have diverged intentionally: BigInt for sign, BigRational for value.

det_exact_f64 fast filter — evaluated and deferred

Adding the fast filter to det_exact_f64 (returning det_direct() when the filter passes) would change semantics: det_direct() accumulates f64 rounding throughout, while the exact path gives the correctly rounded f64 (nearest f64 to the true mathematical value). These can differ by a few ULPs.

Since the function name promises "exact computation, f64 output", changing this contradicts the contract. Users who want the fast f64 path already have det_direct() (2ns, D ≤ 4).

What's already addressed

• ✅ Shared validation (validate_finite)
• ✅ det_exact_f64 delegates to det_exact (no duplication)
• ✅ Clean internal pipeline around bareiss_det_int
• ✅ det_sign_exact optimized to skip BigRational entirely

Remaining "double work" scenario

Calling both det_exact() and det_sign_exact() on the same matrix still runs bareiss_det_int twice. This can only be fixed by caching (interior mutability), which contradicts the Copy-able, zero-overhead Matrix design. Not worth the complexity.

Closing as addressed by #64.