diagram: applySimSpecChange full-payload read-modify-write can silently revert a concurrent sim-specs commit (lost update) #833

Problem

applySimSpecChange in src/diagram/Editor.tsx (currently around lines 1166-1190) performs a full-payload read-modify-write on sim specs: it reads the CURRENT project.simSpecs from the controller snapshot and builds a complete setSimSpecs payload (all six fields) with the one updated field substituted.

ProjectController.applyPatch calls are not queued/serialized against each other. If a second sim-specs commit fires while the first one's engine round-trip + snapshot refresh is still in flight, the second payload is built from a stale snapshot: it carries the first field's OLD value and silently reverts it (classic lost update).

Why it matters

Correctness: a user edit can be silently discarded with no error and no visible indication, leaving the model with a stale sim-spec value (e.g. reverted dt or stop time).

Severity / reachability

Currently only reachable in a sub-second window (WASM applyPatch + serialize round-trip) that a human tabbing between fields realistically cannot hit -- which is why this is tracked rather than hotfixed. The window would widen if patch application ever becomes slower or genuinely async (e.g. worker offload), so it should not be left to rot.

History

• This predates the issue-every character change in sim specs shouldn't result in a model save #55 commit-on-settle change: the old per-keystroke handlers had the identical read-modify-write.
• The every character change in sim specs shouldn't result in a model save #55 work (commit c011e15) made the race strictly less likely (far fewer patches) but did not fix it; that commit message notes the race is "now tracked separately" -- this issue is that tracking.

Component

src/diagram -- Editor.tsx (applySimSpecChange), ProjectController.applyPatch.

Possible approaches

1. Send a partial setSimSpecs patch containing only the changed field, so concurrent payloads compose instead of overwriting each other.
2. Serialize applyPatch calls in ProjectController (queue them so each read-modify-write observes the previous patch's result).

Context

Identified during the interactive-editing burndown (branch interactive-editing-burndown, PR forthcoming), flagged by the adversarial reviewer of the #55 change and confirmed pre-existing.