SAFETY P0: pressing STOP never makes the arm move - commands sent while held are dropped, never buffered and replayed #66

Owner, 2026-10-20 22:05Z: "on the arm, i move the 3d model and it just snaps back. then i hit a stop button and it started moving." A stop that causes motion is the worst possible bug for a public arm.

Likely cause to confirm: commands sent while the server held or refused them (not driver, held, reconnecting) are queued somewhere (client buffer, WebSocket send queue, server queue, the Pi server) and flushed when STOP/resume changes state — or the two STOP buttons on the page do different things (one may be resume).

Done:

1. Commands are latest-wins targets with a sequence number and a timestamp; the server drops any command older than 200 ms or with a sequence ≤ the last applied; nothing is ever queued for later.
2. STOP: the server sets a held state, holds torque at the current pose (no new targets) and discards every pending target. Resume never applies a target sent before resume; after resume the arm stays put until a new command arrives.
3. Exactly one STOP control per layout (with #49); resume is a different, clearly labelled control.
4. HIGH-BAR TESTS (the owner asked for a high bar): (a) property test with a fake Pi that records every target it receives — for random interleavings of drag / slider / STOP / resume / disconnect / turn change, no target reaches the Pi after STOP until resume plus a new command; (b) replay: send 100 commands while held, press STOP, resume — the fake Pi receives zero of them; (c) browser test (playwright) on the real page: drag, STOP, resume — the recorded stream matches; (d) once the crew can SSH the Pi (trevato/forge#3470), a hardware-in-the-loop check with the real arm at low speed, logged.
5. The pull shows the recorded command streams from (a)–(c).