CLAUDE: peak kernel precision two-step - templated body, float instantiation corr2D_peak_eig_f (Andrey's methodology)

Step 1 (double vs double Java oracle) was the validated state; the body is
now a template on the accumulator type with two extern-C instantiations:
corr2D_peak_eig (double, the oracle-matched reference) and corr2D_peak_eig_f
(float, ~64x cheaper FLOPs + half the shared footprint - kept adequate for
full-frame, Andrey's ruling). tp_proc_exec_corr2d_peak grows a use_float arg;
NVRTC module = 25 kernels. All three tests run BOTH and report float-vs-double
grouped stats (dx/dy px, strength rel, eigvec abs, lambda rel).

Step 2 measured:
- synthetic: dx/dy <= 4.8e-7 px, lambda <= 9.4e-7 rel; eigvec 0.031 ONLY on
  the (near-)isotropic tiles where the direction is ill-defined (float can't
  fire the oracle's e=1e-12 branch) AND unused (setEigenTransform degenerates
  to isotropic weighting when lambda0~lambda1) - documented in tp_peak.cu.
- REAL case (4 iterations x 150 tiles): dx/dy <= 7.2e-7 px, strength
  IDENTICAL, eigvec <= 8.9e-5, lambda <= 1.2e-6 rel - 4+ orders below the
  ~0.01 px measurement noise. Float is adequate for production; double stays
  as the validation/oracle tier. Double regression unchanged (synthetic 0 /
  9.6e-17; real case ALL PASS).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>