Redis-backed distributed rate limiting and queueing

[stationeros]

Status

v0.3.0 ships durable database-backed coordination and persistence with SQLite.

Problem

v1 keeps rate limiting and async execution state in-process. This breaks down once the service runs across multiple replicas.

Goal

Move rate-limit coordination and job queueing to Redis so multiple instances share the same execution budget.

Scope

• Redis-backed token bucket implementation
• Redis-backed queue for async jobs
• worker lease and retry semantics
• graceful degradation when Redis is unavailable

Acceptance criteria

• multiple replicas enforce the same per-tool rate limit
• async jobs can be produced on one replica and consumed on another
• tests cover retry, lease expiry, and duplicate-delivery handling

[snakefood3232]

Moving rate-limit coordination and job queueing to Redis for multi-replica support is a critical upgrade. I'd handle this by implementing a Redis token bucket and queue with atomic operations for leases and retries, ensuring graceful fallback. Can have a PR with tests for lease expiry and duplicate handling up in 2 days. I've built similar distributed rate-limiting systems for production APIs.