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

@@ -453,6 +453,29 @@ The proxy runner handles authentication, MCP protocol framing, and session
 management; it is stateless with respect to tool execution. The backend runs the
 actual MCP server and executes tools.
 
+### Session routing for backend replicas
+
+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` 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
+
+The `SessionStorageWarning` condition only fires when `spec.replicas > 1`
+(multiple proxy runner pods). It does not fire when only `backendReplicas > 1`,
+but Redis session storage is still strongly recommended in that case to ensure
+reliable per-session pod routing.
+
+:::
+
 Common configurations:
 
 - **Scale only the proxy** (`replicas: N`, omit `backendReplicas`): useful when