One noisy device can fill the entire shared queue

The shared IngestQueue is sized generously, but nothing currently stops one device from claiming all of it. DeviceRateLimiter is already wired into both POST /events and POST /events/batch — both already call rate_limiter.allow(event.device_id) before enqueueing and reject with 429 when it returns False — but allow() always returns True, so a single noisy device can starve every other device sharing the same process's capacity, and there is no fairness protection at all today.

DeviceRateLimiter.allow(device_id) is a stub that always returns True, no matter how many requests a given device_id has made or how fast, even though Settings.per_device_rate_limit_per_second is already threaded into its constructor.

1. pytest practice_tickets/tests/test_ticket_10_rate_limiter.py -v — calls allow("d1") 50 times back-to-back against a 5/sec limit and confirms none are throttled.

This is a fairness problem, not a capacity problem: the queue itself is sized generously, but nothing currently stops one device from claiming all of it. A token-bucket or sliding-window counter keyed by device_id is the standard shape for this (a simple fixed window is easier to implement correctly than a true sliding window, at the cost of allowing bursts right at window boundaries).

Look at DeviceRateLimiter.init — it already stores limit_per_second. allow() needs some per-device_id state (a dict keyed by device_id, holding whatever a token-bucket or fixed-window counter needs) to decide, on each call, whether this device is currently within its budget.