RateLimitingMiddleware and SlidingWindowRateLimitingMiddleware stored per-client limiters in an unbounded defaultdict keyed by client id. Every distinct client id created a permanent entry that was never evicted, so a long-running server facing many transient clients (or attacker-supplied ids) leaked memory without bound.

This replaces the defaultdict with an OrderedDict used as an LRU cache, capped by a configurable max_clients (default 10,000). Accessing a client moves it to the most-recently-used end; inserting past the cap evicts the least-recently-used entry. Eviction is safe because an evicted client was idle long enough for max_clients other clients to be more recent — by which point its token bucket would have refilled (or its sliding window expired) anyway, so it is indistinguishable from a fresh client. max_clients < 1 is rejected at construction. The same fix is applied to both middlewares. Note the internal storage attribute is renamed limiters → _client_limiters to reflect that it is no longer a public auto-vivifying dict.

RateLimitingMiddleware(max_requests_per_second=10, max_clients=10_000)
# memory is now bounded; LRU clients are evicted instead of accumulating

Refs #4053 — fixes Bug 1 (rate-limiter dicts never evicted). Bugs 2 and 3 (FilesystemProvider lazy-lock race, unbounded _warned_files) are out of scope here.