A Redis outage crashes every redirect instead of degrading to DB-only

Redis is an optimization layer for this app -- the source of truth is always Postgres. But today, if Redis becomes unreachable for any reason (a restart, a network blip, hitting a memory limit, a bad deploy of the Redis service itself), every single GET /<slug> request crashes with a 500, because nothing catches the connection error. This inverts the whole point of a cache-aside pattern: the one thing a cache is supposed to do is fail open (fall back to the source of truth, just slower) -- instead, this app currently fails closed (an unrelated infra outage takes down 100% of redirects, the app's single most important endpoint, even though Postgres itself is perfectly healthy).

Neither resolve_short_url nor app/utils/cache.py's helper functions have any exception handling around the Redis calls. A ConnectionError (or any other redis-py exception) from get/setex/delete propagates straight up and crashes the request.

1. pytest practice_tickets/tests/test_ticket_20_redis_degradation.py -v (simulates redis.exceptions.ConnectionError on every Redis call).
2. Observe: GET /<slug> for an active, non-expired link raises ConnectionError and 500s, instead of falling back to the DB and returning 302.

This requires deciding where to catch the failure: too broad (wrapping the entire request) risks masking real bugs as "Redis is down"; too narrow (only around get, not setex) leaves half the failure modes uncovered. The right shape is narrow, targeted try/except around each Redis call specifically, treating a connection failure as equivalent to a cache miss (for reads) or a no-op (for writes/invalidation) -- with a log line so an actual outage is still visible in ops, not silently swallowed forever.

Look at app/utils/cache.py's three functions (get_cached_url/set_cached_url/invalidate_cache) as the natural place to contain this -- each one already has a single, clear responsibility, so each can decide its own safe fallback (a failed get behaves like a miss; a failed set/delete just means "the cache did not get updated this time," always a safe, if suboptimal, outcome for a cache-aside design). Import redis.exceptions.ConnectionError (and consider redis.exceptions.TimeoutError) specifically, rather than a bare except Exception, so a real bug elsewhere doesn't get silently absorbed too.