sabotage arm 'worker_env is not applied to a running worker' escapes under full-suite load #134

Found 2026-10-22 by the #131 lane (PR #133). In a full tests/sabotage.py run (225 caught, 6 skipped for lack of OMX_CLAP_HOST) ONE arm survived: "worker_env is not applied to a running worker". Run alone three times on the branch, and on a clean main worktree, the arm is caught (goes red) every time. So the guard is real but the arm's detection is load-sensitive: under the load of the full run the sabotaged build still passes the check.

A sabotage arm that can survive a correct guard is a false alarm; one that survives a BROKEN guard would be worse. Make the arm deterministic: the check should wait on the worker's own acknowledgement (an event or state read) instead of a time window, and a run of the full sabotage suite under nice with a parallel CPU hog must catch it. Done means: the full run catches it 10 times out of 10 with a load generator running; the arm still goes red on a real break (restore, break, see red, restore).