New Interpolation Strategies

ninterp currently ships Linear, LinearUniform, Nearest, Step/StepLower/
StepUpper. This tracks strategies worth adding on top of those, based on auditing a
real downstream consumer (QCDLab/neopdf) that
hand-rolls all of the following today because none of them exist in ninterp.

• CubicC2 (originally proposed here as CubicSpline) -- global C² cubic
  spline, 1D-ND, configurable boundary condition (NotAKnot/Natural/Clamped/
  Periodic). In progress via #55: renamed from CubicSpline, and a full
  corner-derivative cache added for Interp2D/Interp3D so 2D/3D queries are an O(1)
  Hermite-patch lookup instead of re-solving the recursive tensor decomposition on
  every interpolate() call. This supersedes the Bicubic/Tricubic proposal
  originally listed below: that capability is now CubicC2's own corner cache, not a
  pair of separate dimension-specific types.

• CubicC1 (originally proposed here as CubicHermite) -- local cubic
  Hermite spline (C¹, finite-difference derivative estimate). No global tridiagonal
  solve, cheaper to build than CubicC2, and in the same family as the recipe LHAPDF
  uses, so it's not interchangeable with a natural spline for consumers wanting that
  kind of local, no-global-solve behavior. Not a drop-in for LHAPDF/neopdf parity,
  though: LHAPDF's bicubic scheme is an order-dependent, successive-1D construction
  (interpolate x first, derive the y-derivative from finite differences of the
  already-x-interpolated cross-sections), not a symmetric per-knot corner-derivative
  spline; CubicC1 stays symmetric and order-independent, matching CubicC2's
  existing architecture. QCDLab/neopdf reimplements the LHAPDF recipe five times:
  LogBicubicInterpolation (2D), LogTricubicInterpolation (3D),
  LogFourCubicInterpolation (4D), LogFiveCubicInterpolation (5D), plus a standalone
  consolidated InterleavedHermite whose own doc comment notes it uses "the same
  algorithm" as the others; consumers wanting exact LHAPDF parity still need their own
  implementation, as neopdf already has.

  Ship v1 plain: derivatives from unclipped finite differences -- the same
  derivative-estimate principle neopdf's own version uses at the 1D level, though the
  overall construction differs as above -- the minimum bar. The derivative-estimate
  method is a #[non_exhaustive] enum from day one, not a bool or a field bolted on
  later, so monotonicity-preserving and alternative derivative formulas can land
  afterward without a breaking change:

  #[non_exhaustive]
  pub enum CubicC1DerivativeMode {
      FiniteDifference,
      // Pchip: Fritsch-Carlson monotonicity-preserving clipping.
      // Akima: weighted-secant-slope derivative estimate, resists overshoot near
      // flat regions; standard alongside Pchip in scipy/GSL/MATLAB.
  }
  

  Gate any future non-FiniteDifference mode out of Strategy2D/Strategy3D::validate
  until its 2D/3D mixed-partial behavior is verified (the 1D formulas are
  well-established literature, the mixed-partial case for each isn't). Loosening a
  validation error later is non-breaking; shipping an unverified guarantee isn't as
  easily undone.

• Chebyshev -- global/spectral polynomial interpolation, barycentric
  formula on Chebyshev-spaced nodes. Confirmed in scope: a different interpolation
  family entirely, not competing with the cubic family above, useful for smooth
  functions needing high accuracy from few points. neopdf implements this twice --
  LogChebyshevInterpolation and a second, batch-oriented
  LogChebyshevBatchInterpolation that recomputes the same barycentric-weight math
  for multi-point speed. The latter carries its own
  TODO: potentially merge this with LogChebyshevInterpolation -- neopdf considers
  this duplication unresolved on their end too.

Coordinate-space transforms (tracked separately)

GridTransform/Transform/ValuesTransform: see #56. Not a new interpolation
method -- a composable wrapper around any strategy above (or Linear/Nearest) that
interpolates in a transformed coordinate space (log, sqrt, reciprocal, ...) instead of
the raw one -- useful for data spanning many orders of magnitude, known nonlinear
relationships, or keeping output within a range a raw spline can't guarantee.
QCDLab/neopdf hand-rolls a Log*-prefixed strategy per combination today
(LogBicubicInterpolation, LogTricubicInterpolation, LogChebyshevInterpolation)
precisely because there's no composable alternative; this retires that naming
convention in favor of one wrapper type, rather than the crate growing a matching
Log* type per strategy.

Other future directions (not committed, no known consumer yet)

Distinct from everything above: nothing here is backed by a real downstream consumer
hand-rolling it today, which is the bar the rest of this issue was held to. Listed so
they're not lost, not because they're planned.

• Tension spline -- cubic spline with a tunable tension parameter trading
  curvature-continuity for overshoot control. Geophysics/GIS domain (GMT's
  greenspline).
• Trigonometric/Fourier interpolation -- for uniformly-sampled periodic signals,
  the DSP-native alternative to CubicC2's Periodic boundary condition.

Non-goals

• No radial basis function / scattered-data interpolation, no kriging, no
  smoothing/regression splines -- out of scope for a rectilinear-grid, exact-
  interpolation crate. Different problem class (fitting through noisy or non-gridded
  data), not a gap in this one.
• No B-spline basis or approximating/smoothing B-spline as separate strategies --
  either the same interpolant CubicC2 already produces via a different internal
  algorithm (not a new capability), or curve fitting rather than interpolation, same
  reasoning as the point above.

Start by choosing one unchecked strategy, CubicC1 or Chebyshev, and review the existing Linear, LinearUniform, Nearest, and Step strategies. For CubicC1, also inspect the Strategy2D and Strategy3D validation paths named in the issue. Done means the selected strategy meets its stated dimensional, numerical, and validation requirements with appropriate tests.