fix: use maxSurge=0 rolling update to avoid CPU pressure on small cluster

During rolling updates with the default maxSurge=1, an extra surge pod was
created temporarily (3 pods instead of 2), causing all 3 nodes to report
"Insufficient CPU" and delaying scheduling past the Jenkins rollout timeout.

With maxSurge=0 / maxUnavailable=1, one old pod terminates first before a
new one starts — pod count stays at 2 throughout, no extra CPU needed.

Also increase Jenkins rollout timeout from 300s to 600s as a safety net
for CPU-constrained nodes that may still need extra scheduling time.

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

k8s/base/frontend/deployment.yaml

@@ -7,6 +7,11 @@ metadata:
     app.kubernetes.io/component: web
 spec:
   replicas: 2
+  strategy:
+    type: RollingUpdate
+    rollingUpdate:
+      maxSurge: 0       # Don't create extra pods during update — avoids CPU pressure
+      maxUnavailable: 1 # Terminate one old pod first, then start new one
   selector:
     matchLabels:
       app.kubernetes.io/name: frontend