/readyz reports 200 even when Redis is unreachable

/readyz is what a load balancer or Kubernetes uses to decide whether to send traffic to this gateway instance. Every rate-limited route depends on Redis being reachable -- if Redis is down, rate limiting either silently fails open or every request 500s, depending on the route. Right now /readyz returns HTTP 200 even when its own Redis ping fails, so nothing upstream of the gateway (load balancer, k8s readiness probe, an on-call dashboard) can tell the difference between "fine" and "broken." A Redis outage becomes an outage that traffic keeps getting routed into, discovered only when customers start complaining -- not a clean, automatic failover.

GET /readyz always returns HTTP 200, even in the branch that already detects the Redis ping failure and builds a {"status": "degraded", ...} body for it.

1. Start the app with a RateLimiter whose backing Redis is unreachable (a ping() that raises).
2. GET /readyz.
3. Observe: HTTP 200, body {"status": "degraded", "reason": "..."}. Expected: HTTP 503 with the same body.

An HTTP status code is often the only thing a health-check consumer looks at -- load balancers, k8s probes, and uptime monitors frequently do not parse the body at all. A degraded state reported via a 200 is functionally the same as not reporting it, because readyz()'s failure branch never calls anything that sets the response status away from the default.

Look at the two return paths in readyz(). One of them already knows it is in the failure case (it is building the "degraded" body) -- it just never tells Starlette what status code to send. Response objects passed into a handler as a parameter are mutable; look at how other status-code-less handlers in this codebase communicate a non-200 status back to Starlette while still returning a plain dict body.