fix(shared): serialize TokenBucket.waitAndConsume to prevent token over-issue (closes #209)

[williamzujkowski]

Completes #209 (the rate-limiter half; the retry.ts half is in #212).

Bug

TokenBucket.waitAndConsume computed a single waitMs, slept, then did this.tokens -= count unconditionally. N concurrent waiters that found the bucket empty all scheduled the same wait, woke together, and each subtracted from a bucket that refilled enough for only one → tokens goes negative and the limiter silently exceeds its rate. It's used by the annotator and the CourtListener client; today's call sites are sequential so it's latent, but it's a real correctness bug in a shared primitive and the existing test only exercised a single waiter.

Fix

• Serialize waiters via a FIFO promise chain (mutex): each waiter awaits the prior one, then loops — refill(), and only tokens -= count after re-checking tokens >= count. Concurrent waiters can never over-issue, and ordering is preserved.
• Add a guard: waitAndConsume(count > capacity) throws RangeError instead of waiting for a deficit that can never close.

Tests

• concurrent waiters served FIFO across separate refill intervals without driving tokens negative;
• capacity guard throws.
• Existing tryConsume/refill/waitAndConsume tests unchanged. shared 27 pass; annotator 76 / build 8/8 unaffected.

🤖 Generated with Claude Code