bug: field_matvec_rls wrong under shared-weight broadcast (wc=1, C=2) — main's Test CI red since #59

[balbasty]

Summary

main's Test workflow has been failing since PR #59 merged (commit d07e987c, run 30717973295, ~10h ago as of filing) — test_reg_field fails with 29/8440 checks wrong in run_2d_matvec_rls_unit_weight (the regression test #59 added for kernels#40). This was not caught before merge: the agent that authored #59/#64 explicitly flagged it could not complete a full local make test run due to machine contention, and nobody checked post-merge CI before proceeding — that's on me (the triager), noted for process, not blame-shifting.

Reproduced identically across all 3 bound-policy CI matrix legs (bounds=static, bounds=dynamic, bounds=cuda-default) — deterministic, not flaky. Also reproduces unchanged on the unrelated fastfields-lib#4 CUDA-stream-widening PR (#61), confirming it's inherited from main, not caused by that PR.

The pattern (this is the useful part)

Every single failure has wc=1. Not one wc=2 case fails. The test loop runs both wc=1 (RLS, one shared weight map broadcast across C=2 field channels) and wc=2 (JRLS, one weight channel per field channel) back-to-back with otherwise identical parameters — only the wc=1 (broadcast) leg is wrong:

MISMATCH [field2d_matvec_rls_unit_weight[C=2 wc=1 order=1 bound=3]]: got -0 expected -0.39110906
MISMATCH [field2d_matvec_rls_unit_weight[C=2 wc=1 order=2 bound=3]]: got 1.9946728 expected 2.4464578
MISMATCH [field2d_matvec_rls_unit_weight[C=2 wc=1 order=2 bound=3]]: got -1.7362719 expected -1.8911195
MISMATCH [field2d_matvec_rls_unit_weight[C=2 wc=1 order=2 bound=3]]: got -0.29693745 expected -0.76770114
MISMATCH [field2d_matvec_rls_unit_weight[C=2 wc=1 order=3 bound=3]]: got -15.83972 expected -16.547667
MISMATCH [field2d_matvec_rls_unit_weight[C=2 wc=1 order=3 bound=3]]: got 16.856455 expected 17.118894
... (29 total, full list in CI log for run 30718675002 / job 91418616873)
MISMATCH [field2d_matvec_rls_unit_weight[C=2 wc=1 order=1 bound=6]]: got -0 expected -0.39110906

Notable details:

• order=1 (absolute-only, no neighbour terms) fails too — only 1 of 60 elements per bound, always reading -0 where a nonzero value is expected. Since absolute-only has no spatial coupling, this looks like a single mis-indexed voxel (e.g. an off-by-one in the weight-broadcast stride) rather than a magnitude/scale error.
• order=2 (plain membrane_rls, not the bending path reg_field: add field_matvec_rls/diag_rls/relax_rls dispatch + tests #40 touched at all) also fails, with several wrong elements per bound.
• order=3 (bending, where reg_field: add field_matvec_rls/diag_rls/relax_rls dispatch + tests #40's fix landed and the still-open "kernel[0] unweighted" follow-up lives) fails most heavily.

This pattern — wrong only when wc < C and the weight map must be broadcast across channels, correct when wc == C — points at the RLS broadcast path specifically (cpu-impl and/or kernels layer indexing when reading a shared weight channel for multiple field channels), not purely at the kernel-table magnitude issue #40 already covers. The order=2 failures in particular can't be explained by #40 (that fix only touched make_kernel_bending_rls, i.e. order=3) or by the still-open kernel[0] follow-up (bending-only) — so there is likely a second, distinct bug here beyond what #40 scoped.

What's NOT yet known (for whoever picks this up)

• Whether this is a genuinely new regression (something landed between deps: bump impl to the matvec_lame_jrls self-adjointness fix #38/reg_field: add field_matvec_rls/diag_rls/relax_rls dispatch + tests #40's kernel-level verification and now) or a pre-existing bug in the broadcast path that test: check the RLS field operator reduces to the unweighted one at w == 1 #59's test is the first thing to ever exercise at wc=1, C=2 for field_matvec_rls specifically (the earlier run_2d_matvec_rls_symmetry oracle also covers wc=1, but self-adjointness is blind to a broadcast-indexing bug the same way it was blind to reg_field: add field_matvec_rls/diag_rls/relax_rls dispatch + tests #40's magnitude bug).
• Whether flow_matvec_rls/diag_rls/relax_rls share the same broadcast code path and are equally affected (untested by this issue).

Impact / urgency

This blocks the fastfields-lib#4 CUDA-stream-widening series (5 PRs, 3 already merged at the CUDA-only layers; fastfields-cpu-lib#61, fastfields-lib#50, fastfields-dlpack#22 held pending this fix since they'd inherit red CI and, more importantly, ship a real wrong-answer bug). field_matvec_rls/field_relax_rls are also reachable from the Python wrappers today, so this is a live correctness bug in the current main, not just a CI nuisance.

Suggested next step

Isolate with a minimal C=2, wc=1 direct-kernel harness (bypass cpu-lib dispatch first to localize kernels vs. cpu-impl vs. cpu-lib), starting from order=1 (absolute-only, single bad voxel) since it's the simplest reproduction — find which voxel/index is wrong and trace the weight-broadcast read back from there.

Workstream: claude-jitfields-to-fastfields