Name first generated kernel: splined field evaluation (#515)

[krystophny]

Problem

The lazy-fortran stack generates numerical kernels from symbolic definitions,
but none of its ~35 issues touches code that publishes a physics number. This
issue (#515) closes that gap by naming the first SIMPLE kernel that a generated
implementation must replace, and by fixing the measurement instrument that
decides whether the generated kernel is worth shipping.

The other candidates (canonical-coordinate transforms, RK stages) are larger,
more control-flow-heavy, or downstream of the field anyway. The spline path is
the hottest, arithmetic-heavy, straight-line evaluation in the code, and its
derivative variant has exactly the shape symbolic AD produces well — the
evidence (libneo#408 2.16x spline improvement, SIMPLE's own 2.86x batch-spline
speedup) is already in-repo.

Change

• DOC/first-generated-kernel.md — records the decision: the first
  generated consumer is splined_evaluate / splined_evaluate_with_der in
  src/field/field_splined.f90, with the rationale and the fortsym statement
  template (N_sym / N_emit / N_machine / T / X ulp).
• test/tests/test_splined_kernel_bench.f90 — the production-side
  measurement instrument. It measures, on a real NCSX coils workload:
  • T: wall-clock time per evaluation of the value-only and
    value+derivative splined-field kernel (best-of-N), and
  • X ulp: accuracy of the splined Bmod against the direct Biot-Savart
    coils field (the high-precision reference for this kernel).
• test/tests/CMakeLists.txt — registers test_splined_kernel_bench
  (labels unit;performance).

Baseline measured here (gfortran 14, one core):

T (value only)          = ~1.4e-6 s/eval
T (value + derivative)  = ~3.5e-6 s/eval
X ulp (max, Bmod)       = ~2.7e9 ulp vs direct field  (~6e-7 relative)

The ulp figure is spline-interpolation accuracy at the default 62x63x64 grid,
the accuracy the kernel delivers today; a generated kernel must match it or the
golden-record gate rejects it. N_sym and N_emit come from the fortsym toolchain
(external); this PR supplies the SIMPLE-side measurement and the decision.

Acceptance

Golden records are untouched — no production code changes, only a new
measurement test and documentation.

Verified: test_splined_kernel_bench, test_splined_field_derivatives,
test_bder_from_splines, and test_batch_splines all pass.

Closes #515

[krystophny]

Review verdict: Comment

Summary: The benchmark is registered correctly, but its reported performance and accuracy gates are not reliable enough for the stated measurement contract.

Findings:

1. [minor] test/tests/test_splined_kernel_bench.f90:125-135 — The timed region recomputes all sample coordinates, including mod and conversions, on every iteration. This inflates T with workload-generation overhead rather than measuring only field evaluation. Precompute the input points outside the timed loops.
2. [minor] test/tests/test_splined_kernel_bench.f90:80-91 — The comment claims a <1e-3 relative-accuracy gate, but the test only checks max_ulp < 1e13; this is neither a relative threshold nor a meaningful accuracy oracle. Compare relative error directly (and separately compare generated output with the handwritten kernel).

Verdict: Comment — useful baseline, but the measurement claims should be corrected before relying on it for generated-kernel decisions.