feat: Redis-backed response cache backend

[emmanueldirector24-crypto]

Pre-flight checklist

• I searched existing issues and this is not already requested.
• This feature belongs in the OSS gateway, not in a cloud/paid layer.

Area

Observability / Metrics

Problem or motivation

The built-in response-cache plugin only supports an in-memory store today. That's a real limitation for multi-replica deployments (Helm/K8s especially, or anywhere behind a load balancer with more than one gateway instance):

• A request cached on pod A is still a cold miss on pod B, so effective hit rate drops as you scale replicas.
• The cache is wiped on every restart or rolling deploy — no persistence.

Proposed solution

ROADMAP.md already lists "Semantic & Redis-backed caching — beyond the built-in in-memory cache" as a next step. I'd like to scope a first pass to just the Redis KV backend (not semantic/embedding matching), following the existing backend:/dsn: pattern already used for the request-logger and store configs:

- name: response-cache
  type: guardrail
  stage: before_request
  config:
    backend: redis
    dsn: redis://localhost:6379/0
    ttl: 300s
    max_entries: 10000

Would a PR adding this be welcome? Happy to open one and iterate on the config shape if the approach looks right.

Alternatives considered

No response

Additional context

No response