Euler-Lagrange integration accepts ~2.3x more ODE steps since #355

[matt-pharr]

Noticed while validating #365 (which is unaffected — its trajectory is bit-identical on both sides of this change).

Symptom

examples/DIIID-like_ideal_example, same deck, same environment, same machine:

ref	integration/nstep_total (accepted)	integration/nstep (saved)
5b6ba34a (pre-#355, matches all July-era runs)	2002	1366
1d30dfba and current develop	4644	2636

Roughly 2.3x the accepted steps, with the saved count following (bands + every save_interval-th step). Since the EL integration dominates wall time, this is approximately a 2x runtime and solution-storage increase on every run.

The trajectory is not wrong — at the saved nodes the solution is bit-identical across #365's merges at both densities, and the resonant quantities agree to ~1e-10. The step controller is simply accepting more, smaller steps.

Ruled out

• save_interval default, the save-band condition, near_q_frac, and the chunking code are textually unchanged across the range.
• The example deck's [ForceFreeStates] settings are unchanged (comment drift only).
• psilim/qlim are identical in the runs (0.995 / 6.200), so the domain and the edge-scan band did not move.

Bracket

5b6ba34a..1d30dfba contains only #355 (ab329276), the #357 docs merge, and a benchmarks cleanup — #355 is the only src change. Plausible mechanism: a numerical change in how the EL matrices or their splines are built (the freeze-control/locstab refactor touched Sing.jl), slightly changing the RHS smoothness and making the Vern9 controller more conservative. Not yet bisected within #355.

Reproduce

git worktree add ../pre355 5b6ba34a
# run examples/DIIID-like_ideal_example in both trees, then compare
# integration/nstep_total in gpec.h5

[logan-nc]

This could be couples to #384's efforts to address #376. Perhaps the reason for the step count change here will provide some insight into why the steps change so much with mpsi or vice versa.