chore(kontinuous): pin Valkey topology to the app autoscale floor

Dev and preprod stay on single-pod standalone (inherited from base values,
now commented explicitly). Prod keeps 1 primary + 2 replicas = 3 pods,
matching app.autoscale.minReplicas. valkey-helm has no HPA, so pinning to
the floor rather than maxReplicas avoids 6× PVCs for cache data that
client code only ever reads via the primary service.

Author: maxgfr

.kontinuous/env/prod/values.yaml

@@ -20,6 +20,10 @@ app:
 valkey:
   replica:
     enabled: true
+    # One replica pod per always-on app pod (= app.autoscale.minReplicas below).
+    # valkey-helm deploys 1 primary + N replicas, so this gives 3 total pods,
+    # matching the app HA floor. valkey has no HPA, so we pin to minReplicas
+    # rather than maxReplicas to avoid over-provisioning cache storage.
     replicas: 2
     persistence:
       size: 1Gi

.kontinuous/values.yaml

@@ -98,7 +98,9 @@ valkey:
   service:
     type: ClusterIP
     port: 6379
-  # Standalone by default. Prod overrides to master/replica topology.
+  # Dev and preprod run a single-pod standalone deployment — cache loss on
+  # restart is acceptable, and it keeps infra cost minimal. Prod overrides
+  # this to a master/replica topology sized against app.autoscale.
   replica:
     enabled: false
   dataStorage: