OverrideSlotService hält genau einen Slot, und ein Usage-Limit stoppt
naturgemäß alle laufenden Tasks gleichzeitig — "mehr Kandidaten als
Kapazität" ist also der Normalfall. Der Coordinator stempelte
UsageLimitAutoContinuedAt aber VOR dem ContinueTask (der Marker ist die
Dedupe-Guard), sodass Kandidat 2..n den Marker bekamen, deren
ContinueTask mit "override slot busy" in den catch flog und sie danach
dauerhaft aus GetUsageLimitAutoContinueCandidatesAsync ausgeschlossen
waren — ein Continue, der nie lief.
- Vorab-Check auf CurrentSlot: bei belegtem Slot bricht der Tick ab,
statt die restlichen Kandidaten zu verbrennen.
- Neuer TaskRepository.ReleaseUsageLimitAutoContinueClaimAsync gibt den
Claim zurück, wenn ContinueTask wirft; danach return, der 30s-Backstop
holt den Rest im nächsten Tick.
- Regressionstest mit zwei Kandidaten, deterministisch über eine
TaskCompletionSource im FakeClaudeProcess (StartInSlot setzt _slot
synchron unter dem Lock, bevor die Arbeit startet).
mika kuns
3dfae30fff