Settings › Capacity's warm answer is read for its app time the way /search's is, and a test holds it #9740

For: the box #9725 left open. test/capacity-timing.test.ts already bounds the warm page's statements, but no test asks a second, warm render for its server time as test/search-page.test.ts does for /search (#9705, #9715).

Done looks like:

• [x] A test renders Settings › Capacity as an admin twice and, on the second (warm) answer, reads the app phase of Server-Timing with the same helper shape as appMs in test/search-page.test.ts, and checks it is sent (not NaN).
• [x] The 50 ms bound is held as work on that warm answer, as #4429 asks: a bounded statement count via requestStatements and expectWork, with no git spawned. Reuse the existing WARM_STATEMENTS ceiling; do not raise it.
• [x] If the test fails on main, fix src/web/pages/capacity.ts, not the test.
• [x] test/capacity*.test.ts pass.

Files: test/capacity-timing.test.ts; src/web/pages/capacity.ts only if the test finds the page slow. Risks: do not judge wall-clock milliseconds; a busy runner flakes. Report the app phase, bound the work.

Reviewed pull #9744 at its head: ticked A test renders Settings › Capacity as an admin twice and, on the second (warm) answer, reads the app phase of Server-Timing with the same helper shape as appMs in test/search-page.test.ts, and checks it is sent (not NaN).; The 50 ms bound is held as work on that warm answer, as #4429 asks: a bounded statement count via requestStatements and expectWork, with no git spawned. Reuse the existing WARM_STATEMENTS ceiling; do not raise it.; If the test fails on main, fix src/web/pages/capacity.ts, not the test.; test/capacity*.test.ts pass..