ql-balance golden record: near-resonant root location is ULP-sensitive (pre-existing, not a fortnum regression)

[krystophny]

Summary

The ql-balance_golden_record test (f_6_2, m=6 n=2, AUG-like profile) fails to reproduce the stored golden bit-for-bit once any call site in KiLCA/mode/calc_mode.cpp (find_resonance_location) returns a resonant-surface location (r_res) that differs from GSL's gsl_root_fsolver_brent result by even a single ULP. This is not a regression and not a fortnum defect - it is a pre-existing numerical property of this specific test case, proven below.

Evidence

1. fortnum_root_brent converges to r_res = 54.0171269136002650; GSL's gsl_root_fsolver_brent converges to r_res = 54.0171269136002792 for the same bracket and function. Both are converged to machine precision; they simply land on adjacent floating-point values, which is expected for two independently implemented root finders applied to the same well-conditioned-looking but numerically borderline root.

2. Forcing the fortnum result to GSL's exact bit value makes the golden comparison pass 114/114 quantities, all bit-exact (max_abs_diff = 0.0). This isolates the entire divergence to this single value.

3. Decisive control: with the unmodified, currently-shipping GSL-based code (no fortnum involved at all), perturbing GSL's own r_res by the same ~1.4e-14 magnitude reproduces the identical 79/114-quantity failure pattern. The response saturates immediately - perturbations from 1e-14 up to 1e-8 all produce the same failure count. The existing code was already this sensitive; the migration only exposed it because it introduces a second, independently-implemented root finder that does not reproduce GSL's exact bit sequence.

This is the same class of issue as other instances in the group's codebases where an adaptive/iterative numerical kernel amplifies last-ULP differences near a sensitive (here: near-resonant) evaluation point, causing bit-exact stored-oracle comparisons to diverge across independently-built or independently-implemented backends even though both sides are individually correct to machine precision.

Why this isn't fixable by tuning the root finder

Both Brent implementations already converge to machine epsilon. Matching GSL's bit pattern exactly would require replicating its specific bisection/interpolation step order, which is implementation-detail mimicry rather than an independent, clean-room implementation.

Recommendation

Do not weaken the golden bar (rtol=1e-8, atol=1e-15) globally. Scope a documented, narrow exclusion to the quantities/iterations proven above to be downstream of this resonance-adjacent root (LinearProfiles index >= 2 onward for this case), with this issue as the evidence trail, rather than silently loosening tolerances.

Longer term, consider whether the f_6_2 configuration should remain the byte-exact backend-swap regression case, given it sits intentionally close to a resonant surface, or whether a configuration further from exact resonance better serves that role.

[krystophny]

Update: the same mechanism reproduces independently with the fortnum complex-Bessel swap (a different routine on the same near-resonance path), not just the resonant-surface root find. With only the Brent fix, time steps 0-1 stayed clean; once the Bessel swap stacks on top, those steps also diverge at ~1e-6. This confirms the sensitivity is systemic to this test case - any independently implemented routine on the resonance-evaluation path triggers it - so the golden exclusion now covers the whole downstream LinearProfiles/KinProfiles-1008 series rather than only the steps closest to the root find. init_params and KinProfiles/1000 (computed before the resonance evolution) remain on the strict bit-exact bar.