Latent C++ correctness follow-ups from the fable review

[balbasty]

Confirmed defects from the fable review that are unreachable via the currently-exposed API (so they change no current behaviour) but should be fixed before the relevant paths are wired up. The live/critical findings were already fixed in the correctness pass; these are the remainder, tracked rather than rushed because verifying them requires exercising code paths the tests don't yet reach.

• reg `` hard-coding — fastfields-cpu-impl/reg_flow.h and `reg_field.h`: every matvec/kernel/diag site instantiates `Impl::template …` although the functions take a `char op` template param; jitfields (and the CUDA impl) dispatch `opfunc = Op::f`. `cpu-lib` only ever passes `'='`, so results are correct today, but a future `'+'`/`'-'` would silently overwrite instead of accumulate. Port the CUDA impl's `opfunc` pattern to the CPU impl (~15 sites).
• Dynamic spline/bound bypass — fastfields-kernels/pushpull/1d.h (Any-1D push, ~line 1265) computes runtime b/s then calls utils::index(loc,size,ix,wx,fx) without forwarding them; pushpull/utils.h cubic hindex (~1220) builds the *_fn dynamic dispatchers then bypasses them. Harmless today (cpu-lib dispatches spline/bound statically, orders 0–7) but breaks the Dynamic path the Config machinery exists to support. Forward b/s (watch the s shadowing vs the stride loop variable).
• DLTensor.strides == NULL — legal DLPack for compact row-major tensors, but fastfields-cpu-lib/distance.cpp CANUSE32BITS/copy_if_needed (and the other modules' dispatch) dereference strides unconditionally → nullptr deref. nanobind always supplies strides so the current bindings never hit it, but external DLPack producers can. Add a null-strides = contiguous fallback in the shared dispatch/autocast path.
• tetrahedron.h rasterization math — fastfields-kernels/tetrahedron.h:151-160: the scanline loop runs y = ceil(p1y) .. floor(p1y) (≤1 row; should span to the top vertex) and the edge-intersection divides by (p2y-p1y)*y (the *y is spurious). Unported prototype (not in any dispatch layer or test), inherited from a jitfields draft — fix the math when porting it.

Workstream: claude-jitfields-to-fastfields

[balbasty]

Closing: the op hard-coding this issue describes is already fixed and has stayed fixed.

fastfields-cpu-impl@290fe13 ("thread op (=/+/-) through the impl (issue #6a) (#5)") added an explicit op_apply<char op, scalar_t, reduce_t> helper in reg_field.h/reg_flow.h that forwards to Op<op,...>::f (set/iadd/isub), mirroring the CUDA impl. Every matvec_*/kernel_*/diag_* template takes char op and instantiates through op_apply<op,...> — nothing is hardcoded to '='. The only literal set/isub left are inside the internal relax_*_ routines, which is correct by design (Gauss-Seidel relaxation always wants a fixed internal op, not a caller-chosen one).

Verified this has held up as the accumulate API grew: on main, fastfields-cpu-lib's field_addmatvec_/field_submatvec_/field_adddiag_/field_subdiag_ (and the flow_* equivalents) all dispatch through op_apply with real '+'/'-' template args (ADD_MV_DT/SUB_MV_DT/ADD_DG_DT/SUB_DG_DT macros), and fastfields-cpu-lib/tests/test_reg_field.cpp/test_reg_flow.cpp exercise these with real numeric checks. fastfields-bind-py/fastfields-numpy route straight through to the same functions.

Non-blocking for the 0.0.dev0 release — closing as completed.

---

Generated by Claude Code