Redirect's DB fallback resolves deactivated links once the cache is cold

Independent of the delete-cache-invalidation ticket (DELETE forgetting to invalidate a warm cache entry), there is a second, deeper problem: even once a cache entry naturally expires or the process restarts (Redis cache cold, e.g. after a deploy, a Redis restart, or simply the TTL lapsing), a deactivated link resolves again anyway -- straight from Postgres. A "deleted" link is not actually gone; it just goes quiet for a while and comes back. For anything security- or compliance-sensitive (a takedown, an expired promo, a leaked internal link someone asked to be removed), this means "delete" never really means delete.

short_url = ShortURL.query.filter_by(slug=slug).first() in the cache-miss branch of resolve_short_url has no is_active=True filter.

1. Create a short URL, then DELETE /api/urls/<slug> # 204
2. Restart the Flask process, or wait out the cache TTL, or flush Redis -- anything that clears the cache entry for that slug.
3. curl -s -o /dev/null -w "%{http_code}\n" http://localhost:5000/<slug>
4. Observe: 302 -- should be 404 forever, this link was deleted.

This bug and the delete-cache-invalidation ticket look similar (both let a deleted link keep resolving) but they are different failure modes with different fixes: one is about not clearing a cache entry that already exists, the other is about the DB fallback trusting a row it should not. Fixing only one of them still leaves a deleted link resolvable through the other path -- they need to be fixed independently, which is exactly why they are separate tickets with separate, decoupled tests (this one never even touches the cache; it hits a guaranteed-cold slug directly).

Compare this query against the query the original, correct version of this endpoint used (see: any other .filter_by(slug=..., is_active=True)-style lookup elsewhere in the file, or think about what "deactivated" should mean for the one endpoint whose entire job is serving the public redirect).