Benchmark hygiene: tag runs CONTENDED from client-side load, and verify the debug capture is non-empty before trusting a run

Two lessons from recording timed browser sessions against a remote back end:

1. Log the client machine's 1-minute load at the start and end of every run, and sample it every 5 s during the run. Flag the run CONTENDED if the max goes past a threshold (we used 12 on a laptop where 'quiet' meant < 8). Load at the start isn't enough. One run started at 4.9 and peaked at 37.7. That run showed a 20x 'speedup' on one step and failures on another, and both were artefacts. A start-of-run gate alone would have accepted it.

2. If a run's point is a server-side debug timeline, check that the debug file has bytes *before* you spend a quiet window on it. Our wrapper did exec launcher "$@" --debug 2> >(stamp | tee -a file >&2) over ssh. The file was created but stayed at 0 bytes for the whole run, so the window was wasted. The launcher itself rewires fds (node helper.js 3>&1 1>&2), so stderr may not go where you expect. A 10-second smoke test (one cheap request, then wc -c on the log) catches this.

Also: when a run fails in a strange way (a step that worked before now fails in ~15 ms), treat both the fast numbers and the failures as unknown until a clean redo. Don't explain one and keep the other.