Take spring attachments under the lock before iterating them

[drbergman]

dynamic_spring_attachments() runs inside the mechanics parallel-for and walks pCell->state.spring_attachments with no lock. That vector is not private to the thread: another thread running the same function for a neighbouring cell calls attach_cells_as_spring(), which reaches into this cell's spring_attachments and push_back()s.

Those writers serialize on the unnamed critical inside Cell::attach_cell_as_spring() / Cell::detach_cell_as_spring(). The read did not take it. A concurrent push_back that reallocates leaves the loop indexing a freed buffer, and the next iteration dereferences whatever it finds.

Change

Copy the vector under the same critical the writers use, then walk the copy. One hunk, one file, no API change. The existing loop form and traversal order are preserved.

The lock is deliberately not held across the loop body: detach_cells_as_spring() takes the same unnamed critical, and OpenMP criticals are not reentrant — holding it would deadlock.

Evidence

Reproduced on a user model that faults reliably. 60 runs per arm, 4 threads, -O3:

arm	n	crashes
baseline	60	10 (16.7%)
this change	60	0
baseline, 1 thread	30	0

Cost: +2.4% wall time — paired median ratio 1.0237, slower in 9 of 9 paired blocks, and independently 1.0237 in a separate campaign.

Scope

This fixes the crash, and only the crash. Two things are deliberately left alone, both predating this patch:

• The attachment half still reads .size() outside the lock (three places), so the function is not data-race-free. It is crash-free. TSan will still flag it.
• attach_cells_as_spring() / detach_cells_as_spring() each take the critical twice, once per cell, so a pair operation is not atomic. An interleaving can leave a one-way spring — A pulls toward B while B feels nothing, since standard_elastic_contact_function applies force to pC1 only.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.