Reject a profile that its evaluator cannot evaluate

[CharlesCNorton]

CheckProfile requires a spline profile to carry knots and requires the two arrays to have the same length, but not to be long enough to evaluate. Below their knot count the evaluators return 0.0 for every s after one line on stderr: evalAkima and evalCubic need four knots, evalLineSegment two.

That is the failure the validation added in #719 exists to prevent, in its own words: an unusable parameterization "reaches the solver as a zero profile, which converges to a silently wrong equilibrium."

Fortran VMEC halts instead. profile_functions.f counts the knots and stops before the evaluator: IF (i < 4) STOP 'pcurr: check s-grid for curr-grid values!', and the same guard on the pressure and iota branches.

Running cth_like_fixed_bdy.json unchanged and then with pmass_type = "cubic_spline" over three knots:

	two_power (as shipped)	cubic_spline, 3 knots	cubic_spline, 4 knots
exit	converged	converged	converged
presf(0)	4.322928e+02	0.000000e+00	4.322908e+02
betatotal	1.926384e-03	0.000000e+00	1.681736e-03
iterations	121	119	121

The run writes a wout reporting a converged zero-pressure equilibrium while the input asked for 432 Pa. With ncurr = 1 the same holds for the prescribed current, as in #798.

The parameterization table now records how many knots each evaluator needs, 4 for the Akima and cubic families and 2 for the line segments, and CheckProfile rejects an input that carries fewer. NeedsSplineData() becomes that count being positive, so its one caller is unchanged.

The new test drives the three families through IsConsistent one knot short and one knot at the minimum, for the pressure, current and iota profiles; all six rejections fail without the check.

bazel test --config=opt //vmecpp/... //vmecpp_large_cpp_tests/... and pytest pass.

[chatgpt-codex-connector]

Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits.
Credits must be used to enable repository wide code reviews.

[CharlesCNorton]

The opt failure is Threed1ShafranovIntegralsTest/cma at 5.462e-11 against its 5.0e-11 bound, in a test this PR cannot reach: cma uses power_series, whose minimum knot count is zero, so the new check never fires. It passes locally at opt on this branch. #764, now unstacked and standalone, raises that bound to 5.0e-10 from the measured 4.08e-11.

[CharlesCNorton]

Extended to the other ways a profile reaches the solver as zero. The closed-form parameterizations have the same gap as the splines: below their coefficient count gauss_trunc, two_power, two_power_gs and two_lorentz log a warning and return zero for every s, so pmass_type = two_power with am = [1000] converges to a zero-pressure equilibrium; the table now carries the count each needs (2, 3, 3, 8) beside the knot count. The spline evaluators walk their knots in order and the Akima and cubic ones return zero outside them, where Fortran VMEC stops with iflag = -2 and -1; knots out of order gave a different equilibrium without a message (beta 1.80e-3 against 1.68e-3 for the same five points on cth_like_fixed_bdy), and knots ending at 0.9 gave zero pressure beyond them. IsConsistent now requires strictly increasing knots for every spline and knots from 0 to 1 for the Akima and cubic families; the line segments continue their end segments and may stop short. CheckClosedFormProfilesNeedEnoughCoefficients and CheckSplineKnotsIncreaseAndSpanTheRadius cover it.