grepRepos answers at the code budget: the first batch's hits always kept, later batches cut off, abandoned greps still holding their slots #7118

Replaces #7075. Pull #7080 (branch scout/7075-greprepos-race-the-in-flight-batch-again) races each batch of four greps against the time left in codeBudgetMs. Juniper confirmed the race itself is right: the timer is cleared, an abandoned batch cannot reject unhandled, and an infinite budget skips it. Each round found the same two problems:

• Abandoning batch 0 gives a cold search no code at all.
• A module-global abandoned counter lets one caller stop everyone's search.

#7111's grep slots answer the second, so this waits for them.

Start from that branch, rebased on main after #7111.

Done:

• [ ] grepRepos in src/core/search.ts never abandons the first batch, so a search with a finite budget always shows the hits that batch finds. Later batches race the remaining budget, and on a cut the answer says more: true.
• [ ] No module-global abandoned counter. Abandoned greps keep the slot src/search/grep_slots.ts gave them until git exits, and that is the only cap.
• [ ] A search with no budget is unchanged.
• [ ] Tests use an injected grep runner with deferred promises. There is no PATH shim, no sleep and no wall-clock margin. They prove: a cut after batch 0 keeps batch 0's hits; a never-settling later batch does not hold the answer; and one caller's abandoned greps do not stop another caller's search.

Files: src/core/search.ts, test/search-batch-race.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.