Browser speed gates are judged in CPU work

A page that renders in the same work on a quiet and on a busy machine still takes longer on the clock on the busy one, so a wall-clock speed gate blocks merges for reasons that have nothing to do with the change. Judging the browser’s actual work removes that.

The user, 2026-10-15: “merge without pausing, we cant wait for the load to get down, we need a better measurement”.

• The browser speed gates (tab switch, long-chat render, worst long task, LCP and viewport LCP) are judged in CPU work: the renderer main thread’s CPU time from the Chrome trace, plus the server’s CPU time on the critical path.
• Wall-clock values stay as recorded signals, never judged.
• Budgets are generated by the budget tool from measured runs (D-17).
• It extends Q-TX2 to UI performance; merges no longer depend on a quiet host.

What is missing: not built yet. The browser performance gate (tests/performance/regression.test.ts) still judges wall-clock values.