/healthz reports ok even when Redis is down

GET /healthz exists so an orchestrator -- Kubernetes, a load balancer, an uptime monitor -- can tell whether this instance can actually do its job. Every feature this service offers goes through Redis, so if /healthz reports "ok" while Redis is completely unreachable, nothing routes traffic away from a fully broken instance -- every stream and publish call it receives will fail while its health check keeps insisting everything is fine. This is exactly the failure mode a health check exists to catch, inverted into false reassurance, and it stays invisible until the one day Redis actually goes down.

healthz's except branch, which only runs when redis.ping() has just raised (i.e. Redis is not reachable), sets redis_ok = True -- the exact opposite of what just happened.

See practice_tickets/tests/test_ticket_03_healthz_lies.py for a runnable repro: build an app whose Redis client's ping() always raises, then hit /healthz -- it currently still returns 200 {"status": "ok", "redis": true}.

This reads as an obvious copy-paste mistake once you see it -- the except branch is a literal duplicate of the try branch's assignment -- but it's exactly the kind of one-character-away typo that's easy to miss in review, because both branches look like reasonable code in isolation. The bug is invisible on the happy path (Redis working, true 99.9% of the time in dev/CI) and only manifests during the one scenario -- an actual Redis outage -- that a health check is supposed to exist for.

Look at the two branches of the try/except in app/routers/health.py::healthz. One of them is supposed to represent "Redis just failed to respond." Check what value it currently assigns.