A dispatch batch is 100,000 jobs; the job queue holds worker_count * 2 (400). finishWorkBatch submitted every job before consuming a single result, which is a three-way circular wait: main fiber blocked in submit(), waiting for a worker to pop a job workers blocked in Budget.acquire(), which *waits* when exhausted budget released only when the main fiber consumes results Nothing was ever queued for completion. Reproduced on a ccx23 against the real network in 90 seconds with 50 workers and a 256 MiB budget: 1,403 repositories handled, completion_queued_total 0, queue_depth pinned at capacity, workers pinned at 50 -- the same shape as the 27 July whole-network run at 1/50th the machine. Consuming while submitting releases budget as repositories reach the archive's durability boundary, so workers keep draining the queue. The accompanying contract test does NOT reproduce this and passes on the broken code; the pinned simulator's repositories are ~4 KiB, so concurrent demand cannot exceed a budget a single repository fits in. It pins the weaker property that a batch far larger than the queue converges. Its docstring says so. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>