/search greps code within a 30 ms budget and offers "More code results": land pull #3732's branch with its last review asks #3758

Replaces #3385, whose pull #3732 went through three review rounds. The design was found sound each time: an opt-in budgeted grep, the API and palette unchanged, and ?code=all as a plain link. Start from that pull's branch, scout/3385-a-first-search-for-a-word-answers-under (head b061ff06), not from scratch.

Done:

• [ ] As on the branch: in src/core/search.ts, grepRepos takes a time budget as a parameter (no exported mutable module state), checks it before each batch, and reports more when repositories were left ungrepped. /search greps with a 30 ms budget and shows "More code results", linking to ?code=all with kind and live kept. Issues and repositories are always searched in full. The TUI palette and /api/v1 search grep everything.
• [ ] The "More code results" note sits inside the code section, next to the partial list.
• [ ] The stray indent on the import in src/web/pages/search.ts is fixed.
• [ ] Tests run on two apps:

- With a 0 ms budget, the page carries data-more-code, whose href is ?code=all with kind and live kept, and ?code=all removes it. - With a large budget, every row shows and there is no data-more-code. - Each test fails if the note or the budget is taken out.

• [ ] No wall-clock bound in a test (test/flake.test.ts forbids them). The suites for search, studio search, opensearch and the TUI still pass.

Files: src/core/search.ts, src/web/pages/search.ts, test/search-budget.test.ts (or the branch's test). Risk: one batch of four greps can run past 30 ms. That is acceptable; never cut a grep midway.