Add efm_contact to mjData

[smallquail]

Adds mjData.efm_contact, through which flex contact reaches the effective metric as a published pair list rather than as assembled matrix entries.

The field

efm_contact points at an mjEffContact, built once per step. For each pair it carries the participating vertices' dof triples, their weight vectors, and the stiffness — enough to describe the pair's contribution D·wwᵀ without naming how it was detected. The metric's consumers all read that one representation: mjd_effMulAdd applies it, mjd_effPrecContact folds it into the preconditioner blocks. A producer that can express its contacts as pairs reaches every consumer without touching the metric's internals.

Why not assemble it

Contact is a sum of rank-1 terms. Applying D·wwᵀ matrix-free is one dot and one scatter — O(npt) per pair — where materialising it in the CSR costs O(npt²) both to store and to apply. The stiffness CSR also stops growing with the contact set, which keeps its sparsity a function of the mesh rather than of the current configuration.

Behaviour change

This changes passive flex contact. With contact out of the CSR, the metric's block preconditioner no longer picks up its diagonal — and that diagonal was a poor model of the operator. D·wwᵀ with w ≈ [n, −n] penalises the pair's relative motion; its diagonal penalises each vertex's absolute motion, stiffening directions the operator leaves free. Dropping it roughly halves the iterations the qacc_smooth solve needs on model/flex/drape.xml (193 → 104). The trajectory differs accordingly: 216 contacts and 5.31 m/s peak speed at t = 3 s, against 228 and 7.24 before.

API

• mjData.efm_contact (uintptr_t, MJDATA_SCALAR), zeroed in mj_resetData
• mjd_effMulAdd takes flg_contact: the linear solves want the contact term, an energy evaluation that accounts for contact separately does not
• mjd_effContactMulAdd, mjd_effContactCount