Clarify Redis session routing is conditional on Redis being configured

When backendReplicas > 1, the proxy runner only uses Redis for session-to-pod
routing when Redis session storage is actually configured. The previous wording
implied Redis was always used, then contradicted itself in the next paragraph.

Closes #727

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Author: yrobla

docs/toolhive/guides-k8s/run-mcp-k8s.mdx

@@ -457,15 +457,15 @@ actual MCP server and executes tools.
 
 MCP connections are stateful: once a client establishes a session with a
 specific backend pod, all subsequent requests in that session must reach the
-same pod. When `backendReplicas > 1`, the proxy runner uses Redis to store a
-session-to-pod mapping so every proxy runner replica knows which backend pod
-owns each session.
-
-Without Redis, the proxy runner falls back to Kubernetes client-IP session
-affinity on the backend Service, which is unreliable behind NAT or shared egress
-IPs. If a backend pod is restarted or replaced, its entry in the Redis routing
-table is invalidated and the next request reconnects to an available pod —
-sessions are not automatically migrated between pods.
+same pod. When `backendReplicas > 1` and Redis session storage is configured,
+the proxy runner uses Redis to store a session-to-pod mapping so every proxy
+runner replica knows which backend pod owns each session.
+
+Without Redis session storage, the proxy runner relies on Kubernetes client-IP
+session affinity on the backend Service, which is unreliable behind NAT or
+shared egress IPs. If a backend pod is restarted or replaced, its entry in the
+Redis routing table is invalidated and the next request reconnects to an
+available pod — sessions are not automatically migrated between pods.
 
 :::note