Cache reads hang instead of failing fast when Redis is unreachable

## Problem

With a Redis configured but unreachable, `GET /sessions/:id/playing-tracks` **hangs** rather than missing the cache and falling through to the database.

Measured during QA of #116, with `CACHE_REDIS_URL` pointing at a stopped Redis container:

```
poll -> 000 in 8.005842s (curl --max-time 8, i.e. no response)
write -> 000 in 8.002643s
```

The same test against `main` (pre-#116) hangs identically, so this is not new — `ResilientCache` relies on the store *rejecting*, and Keyv/node-redis instead queue commands while the connection is down, so nothing ever rejects and `activeTier()` never gets to mark the tier unhealthy.

## Why it is worth fixing now

`ResilientCache` was built so that "when every configured tier is down the cache degrades to no cache at all, not to a slower one" (docs/architecture.md). That guarantee does not hold today: it degrades to *no answer*.

The SSE push channel added in #116 makes it worse in kind rather than in degree. Opening a stream fetches a snapshot first, so during a Redis outage stream opens hang too, not just polls — and every listener retries, so the hung requests accumulate. That also eats the per-instance connection slots the streams need.

## Suggested fix

Wrap each tier operation in `ResilientCache` with a timeout (a few hundred ms — this is a cache, a slow hit is worthless) and treat a timeout as a failure, so the existing `FAILURE_THRESHOLD` / `PROBE_INTERVAL_MS` health switching takes the tier out of rotation and callers reach the database.

Test it the way the outage actually behaves: a store that never settles, not one that rejects. A rejecting fake already passes today.

## Severity

Hard failure — the audience page stops updating entirely for the length of a Redis outage, where the design intends it to keep working straight off Firestore.