test/settings-timing.test.ts holds on a loaded check machine: its phase accounting is measured against the baseline, not a fixed 5 ms #6916

"GET /settings/tokens names its phases and answers within its budget" failed the check on two pulls that never touched /settings/tokens: #6163 and #6915, whose only shared change was one footer link. On those pulls' head the test passes three runs out of three when run alone. So the check machine's load breaks it. The suspects are the absolute gap <= 5 ms and sum <= app + 0.3 assertions, which a GC pause or a busy core between phases can exceed.

Done:

• [ ] The accounting checks scale with baselineMs, the way expectBudget already scales the 50 ms budget, or take the best of three requests. The test still fails when a phase goes unnamed or a page is really slow (say so in the pull, with how you checked that).
• [ ] The phase-name list is still compared exactly.
• [ ] Look through the other *-timing.test.ts files for the same fixed gap check, and list them in the pull. Do not change them in this pull.

Files: test/settings-timing.test.ts

Before pushing: run bun test test/settings-timing.test.ts five times in a row.