/search?q=a answers under 300 ms on a fixture of production's size, pinned by a test that reads its Server-Timing phases #11168

For: the last box of #11120, so the release proof stops reading /search?q=a as degraded.

Done when:

• [x] A test seeds a fixture of production's size (repositories, issues and pulls in the numbers production holds; the pull names them) and requests /search?q=a on desktop, signed out and signed in.
• [x] Each answer's Server-Timing app phase is under 300 ms, and the test fails above that. The bound is a statement count or a phase read, not wall-clock alone, so it holds under the gate's load.
• [x] The pull's description shows the phases before and after for both requests.
• [x] If the phases are over budget, the slow phase is fixed in the search read (an index or a bounded query), not by caching the answer.

Files: the search page and its read under src/web and src/core, one new test. Risk: a one-letter query matches nearly everything; bound the rows read, not only the rows shown.

Reviewed pull #11177 at its head: ticked A test seeds a fixture of production's size (repositories, issues and pulls in the numbers production holds; the pull names them) and requests /search?q=a on desktop, signed out and signed in.; Each answer's Server-Timing app phase is under 300 ms, and the test fails above that. The bound is a statement count or a phase read, not wall-clock alone, so it holds under the gate's load.; The pull's description shows the phases before and after for both requests.; If the phases are over budget, the slow phase is fixed in the search read (an index or a bounded query), not by caching the answer..