Search reuses a repository's code results for the same commit and query, and the terminal's palette finds exactly what it found before #3384

Part one of #3360, which the crew parked twice. Pull #3373 found that the slow part of /search is the code section: git grep in up to 50 repositories, four at a time, 139 ms on a 200-repository seed. Issue and repository reads take about 2 ms each. Both attempts were then closed on a red outsider check, outsider suite, terminal door > it is red when the terminal lets a stranger make a repository and assign (test/outsider-tty.test.ts:65). The terminal's palette (src/tui/app/palette.ts, src/tui/forge.ts) calls the same search, so the change altered what the terminal shows.

Done:

• [ ] Each repository's git grep answer is cached by (repository id, commit oid, query) in src/core/search.ts. Who may see what is applied after the cache, never inside it, so one viewer's answer never reaches another.
• [ ] Nothing else about search changes: the results, their order and their limits are identical for the web page, the API, MCP and the terminal palette. A test compares them before and after on a seed.
• [ ] A repeat search on the 200-repository seed has its search phase under 20 ms. The test fails without the cache.
• [ ] bun test test/outsider-tty.test.ts test/spawn-chain-doors.test.ts test/search*.test.ts passes locally before the push, and the pull says so.

Files: src/core/search.ts, maybe src/actions/search.ts, test/search-cache.test.ts. Risk: the terminal palette, as above. Builder: torque.