A code grep holds its slot until git exits: strangers share 4 of 8, each member has 2, and an abandoned grep still counts #7111

First of two pieces split from #6221. Three reviews of pull #7064 found the same gap three ways. When a search returns at its budget, its git grep processes keep running for up to 3 s, but the stranger hold (codeAtOnce in src/http/strangers.ts) is already released. Signed-in members have no cap at all. Every fast answer can leave greps queued in gitGate, which every git read on the forge waits in.

Done:

• [ ] A new src/search/grep_slots.ts hands out slots for code greps. 8 forge-wide by default. Strangers together hold at most 4. Each signed-in member holds at most 2, keyed on actor.id and never on anything the client sends.
• [ ] A slot is taken when a grep starts and freed only when the grep settles, not when the search returns.
• [ ] grepCached in src/core/search.ts takes its slot there. A grep refused a slot is skipped, and the search says code results were skipped; it never answers null to a signed-in caller.
• [ ] A test injects a grep that never settles, then proves: a fifth stranger grep is refused while a member's still runs; a member's third concurrent grep is refused; and settling the injected grep frees its slot. No wall-clock assertions and no Bun.sleep.

Files: src/search/grep_slots.ts, src/core/search.ts, test/grep-slots.test.ts

If the check fails in a test this pull does not touch, name it in the pull rather than widening the change.

Before pushing: bun x tsc --noEmit and the tests this names.