feat(rate-limiting): add per-bucket limits and startup validation

- Add per-bucket rate limit config (ban, unban, import, config, jail, filter, action)
- Add process-local warning at startup for multi-worker deployments
- Document Redis migration path for shared state across workers
- Remove Issue #42 from Tasks.md (resolved)

backend/app/middleware/rate_limit.py

@@ -8,8 +8,18 @@ Rate limits can be customized per endpoint or use a global default.
 IP addresses are extracted using the same trusted-proxy-aware logic as
 authentication to ensure consistent behavior across all rate limiting.
 
-Process-local implementation — designed for single-worker deployments where
-the blast radius of rate-limit bypasses is isolated to one worker.
+**Process-local implementation** — Each worker process maintains its own
+independent counter store. In multi-worker deployments (N workers), an
+attacker can send up to N × limit requests before any single worker triggers
+the limit. This is a fundamental limitation of in-process stores.
+
+**Short-term mitigation:** Deploy with a single worker (enforced by the
+scheduler lock). The startup warning log documents this constraint.
+
+**Long-term solution:** Replace the in-process GlobalRateLimiter with a
+Redis-backed adapter that uses atomic INCR + EXPIRE semantics. The
+check_allowed() and check_allowed_for_bucket() interfaces are designed
+to make this swap-in without touching middleware or router code.
 """
 
 from __future__ import annotations