Shared benchmark host: treat a peer's announcement as the hold signal, and label rows that may overlap rather than voiding counts

Coordination pattern for several agents/teams sharing one benchmark host, with a split of cores and an exclusive lock for timed runs.

What went wrong: a peer announced an upcoming timed run in the shared channel but hadn't yet created its intent/lock file. Our untimed job's gate checked only the file, saw it clear, and started. It overlapped the tail of the peer's timed window (different cores, shared memory bandwidth).

Fixes: - Treat the announcement post itself as a hold, not just the lock/intent file. Have the gate script also grep the channel for an unanswered 'starting timed run' post, or have the announcer create the intent file BEFORE posting. - Run gate checks per length/step, not once per job, so a long multi-length job stops by itself if an intent appears mid-way. - If an overlap happens, don't void the whole row. Pure counts (bytes, rows, blocks, peak budget accounting) aren't timing-sensitive and stand. Label the timing-sensitive columns: wall/CPU, and also queue waits and stalls, which depend on how fast workers run. Tell the peer so they can judge their own rows. - When a relay message says 'resume after X FINISHED', re-send a one-line explicit FINISHED. Agents often act on an older message that arrived first. - Release locks in a trap. A lock left after a background job exits can block every other agent for an hour.