Relay readiness hard-requires Redis at replicaCount=1, but chart validation and docs say Redis is only needed for multiple replicas

## Symptom

Fresh Helm install (chart 0.1.6, image `sha-9547891`), `replicaCount: 1`, no `REDIS_URL` / `externalRedis.url` / bundled redis. The relay starts cleanly — all startup probes pass, including the S3 git object-store conformance probe — but the pod sits `Running 0/1` forever: `/_readiness` returns 503 and never recovers. Nothing in the logs states that Redis is the missing dependency; the last startup lines look healthy, so the operator is left correlating a silent 503.

Providing a `REDIS_URL` (tiny in-namespace redis) and restarting the pod immediately fixes readiness.

## Why this is surprising

Every chart-side signal says Redis is optional at a single replica:

- `templates/_validate.tpl`: *"Multiple replicas require Redis"* — the fail branch only triggers when `minimumReplicas > 1`.
- `values.yaml`: *"replicaCount > 1 hard-requires Redis for buzz-pubsub"* (implying =1 does not).
- `values.schema.json` `replicaCount` description says the same.

So a single-replica install validates, renders, deploys — and then never becomes ready.

## Ask

Either (a) the relay drops Redis from the `/_readiness` gate when no Redis is configured and single-replica pubsub can run in-process, or (b) if Redis is genuinely a hard runtime dependency at any replica count, chart validation should fail fast at install time (`redis.enabled` / `externalRedis.url` / `existingSecret` with `REDIS_URL` required unconditionally) and the docs updated. Either resolution beats the current silent-503 behavior; a log line naming the unreachable/missing Redis on readiness failure would help regardless.

Happy to PR whichever direction maintainers prefer.

Related: none found in open issues (searched redis/readiness).

Start with the `/_readiness` behavior and compare it with `templates/_validate.tpl`, `values.yaml`, and `values.schema.json`. Reproduce the single-replica install without Redis, then test the configured-Redis case and determine which runtime and chart behavior should be authoritative. Done means the chart, readiness result, and documentation agree, with a useful failure signal if Redis remains required.

Written by the indexing model from the issue text.