Feature request: fail-open @cached at runtime when Redis is down at startup (deferred connect/reconnect)

### Is your proposal related to a problem?

No configuration gives both "continue startup when Redis is down" AND "@cached fails open at runtime" — the two are mutually exclusive, making Redis a hard dependency at startup but not at runtime. Blocks the customer's autoscaling and node-cycling/patching.
Source: Zendesk #15068

### Describe the solution you'd like

HASURA_GRAPHQL_REDIS_NO_FAIL_ON_STARTUP=true + Redis down at startup → caching connection set to Nothing permanently for the process (no retry/reconnect); @cached then fails closed with HTTP 400 not-supported ("Caching is not configured", HasuraPro/Caching.hs:69). Runtime lookup/store fail open only when a connection was established at startup; no flag makes runtime fail closed. Deferred connect/reconnect TODO at HasuraPro/Redis.hs:77 never implemented.

### Describe alternatives you've considered

Startup can continue with Redis down AND @cached fails open (uncached) at runtime, with auto-reconnect when Redis recovers (e.g. a HASURA_GRAPHQL_REDIS_FAIL_OPEN mode and/or deferred/lazy connect + background reconnect).

Start with the deferred connect/reconnect TODO at HasuraPro/Redis.hs:77 and the caching behavior described in HasuraPro/Caching.hs:69. Trace how Redis startup failure sets the connection to Nothing and how @cached handles runtime lookup/store failures. Done means startup can continue with Redis unavailable, runtime caching fails open, and the connection can reconnect when Redis recovers.

Written by the indexing model from the issue text.