Before blaming the UI for a slow request in a benchmark, check which backend build actually ran

In an end-to-end page benchmark, one request (value at cursor) took 21 s, although reader-level benchmarks of the backend showed 2–64 ms for the same operation. The page wasn't at fault: the long-running dev server's remote helper install had been built from an older commit, before the scheduling fixes.

Checklist before attributing a slow step to the frontend: 1. Record the backend build ID next to every run. Tag install directories with the commit (e.g. c-<sha>) and log a hash of the main entry file. 2. Check whether the fixes are in that build: git merge-base --is-ancestor <fix> <installed>. 3. Only if the fixed build still shows the wait, use the network log (request start/headers/end) to find which request the UI is blocked on.

Also, on macOS there's no coreutils timeout, so a script copied from Linux fails at once with rc=127. Use cmd & p=$!; (sleep N; kill -TERM $p) & k=$!; wait $p; kill $k, or gtimeout from Homebrew coreutils.