POST /api/urls has no rate limiting -- one client can flood the table

Anyone can currently script thousands of POST /api/urls calls per second from a single IP with zero pushback -- filling the short_urls table, driving up Postgres storage/IOPS, and (worse) using this service as a disposable-link generator for spam/phishing campaigns, since the service happily mints links as fast as it can accept connections. This is the single most common abuse vector for any public URL shortener, and there is currently no mitigation at all.

create_short_url validates its input, checks for slug collisions, and inserts -- there is no per-client request counter anywhere in the path.

1. pytest practice_tickets/tests/test_ticket_11_rate_limiting.py -v
2. Or manually: send 21 POST /api/urls requests back-to-back from the same IP within 60 seconds.
3. Observe: all 21 return 201; no 429 is ever returned.

Redis is already in this project specifically for exactly this kind of counter -- a fixed- window or sliding-window rate limiter is a classic Redis use case (INCR + EXPIRE, or a sorted set for a true sliding window). This is a good opportunity to use Redis for something other than the read-through slug cache, and to think about the tradeoffs between a simple fixed window (easy, but allows bursts at window boundaries) and a proper sliding window (more accurate, slightly more Redis calls).

Look at app/utils/cache.py for the existing pattern of "a small module of Redis-backed helper functions used by the routes layer" -- a rate limiter fits the same shape (e.g. app/utils/rate_limit.py with a function like is_rate_limited(identifier) -> bool). Reuse hash_ip/current_app.config["SECRET_KEY"] for the identifier so you are not keying Redis directly off raw IPs. Redis's INCR returns the post-increment value, which combined with EXPIRE (set only on the first increment in a window) gives a simple fixed-window limiter in two calls.