Update regression due to PR6256 (MatrixProjectionMethod fix)

[fredroy]

for

• [LinearSystem] MatrixProjectionMethod: Fix out-of-bounds matrix writes sofa#6256

Why, by Claude:

That randomly-named node is a contact node created at runtime by the penalty collision response, and its size (3, 6, 12, 18, 24) is 3 × the number of active contacts. It's the mapper on the Floor side — and the Floor is simulated="0" moving="0", so it lives outside the solver's subtree, isn't in the mapping graph, and getTopMostMechanicalStates() returns an empty set for it (n1=0). MappingGraph::build only indexes states gathered from the solver's root node, so findStateNode returns null.

So for K(floorContact, beamCollision):

• Old (union): inputs = ∅ ∪ {beamDOFs} = {beamDOFs}, giving the pair (beamDOFs, beamDOFs). With J0 null, computeProjection fell back to the unprojected K * J1 — a 3×48 block — and wrote it at (0,0) of the 48×48 beam matrix. Note the dimensions: 3 rows placed against a state of size 48. It was silently polluting rows/columns 0..2 of the beam's stiffness (DOF 0 being the fixed node), every step there was a contact.
• New (product): inputs1 × inputs2 = ∅ × {beamDOFs} = ∅ → the block is dropped, which is right. Those rows are DOFs of a static object; they aren't unknowns in the system.

The dimensional mismatch is the proof: every dropped block has rows ≠ |a| or cols ≠ |b|; every retained block matches exactly. And the physically meaningful contact term survives — K=(Collision/MechanicalObject1 24, Collision/MechanicalObject1 24) → 48×48 at (0,0), inProduct=1 is still assembled (67 and 64 hits). For a penalty contact against a fixed obstacle, only that diagonal block belongs in the matrix anyway.

What it means

The fix is correct; the reference is stale. It was recorded with the spurious contribution, so removing it legitimately shifts the trajectory — by a small amount, consistent with ERRORBYDOF: 0.0066.