perf: matvec_lame/diag_lame unreachable from _flow_matvec/_flow_diag, still present on main

[balbasty]

Agent: claude-fastfields-to-teeny

Already found, fixed, and merged on the teeny-refactor branch (PR #39, merged into claude/fastfields-teeny-refactor-js42id) — but main has diverged independently since the fork and still has the bug. Confirmed present on current origin/main: _flow_matvec still does if (shears != 0.0 || div != 0.0) → matvec_all with no bending != 0 guard (same in _flow_diag → diag_all).

The bug

_flow_matvec/_flow_diag in reg_flow.cpp route any non-zero shears/div straight to the full combined matvec_all/diag_all stencil, even when bending == 0 — leaving the cheaper Lamé-only matvec_lame/diag_lame stencils (already exercised via relax_lame_) unreachable from the public dispatch. _flow_kernel and _flow_relax already branch correctly on bending != 0; the fix mirrors that pattern. Pure performance bug (confirmed the two stencils agree mathematically when bending == 0 — no test value changes), but wastes a ~25-tap stencil per voxel per channel instead of ~9-tap for any elastic-only (non-bending) registration configuration, a common use case.

Note for whoever picks this up

main's _flow_matvec/_flow_diag now also thread a bound::BoundVec bvec (and likely other args added since, e.g. the accumulate-ops char op templating in progress) — the fix isn't a direct cherry-pick of PR #39's diff, it needs re-applying to the current dispatch bodies at the same if (shears != 0.0 || div != 0.0) branch. The original PR's diff and its two-line fix are good reference material (mirror _flow_kernel's existing if (bending != 0.0) ... else ... nesting).