fix(codeapi-chart): avoid service worker surge rollout

[rschlaefli]

What This Fixes

This PR changes the CodeAPI service-worker Deployment rollout strategy so updates do not require a temporary second service-worker pod.

Staging exposed this with the default Deployment rolling update behavior: one replica rounded to maxUnavailable: 0 and maxSurge: 1, so AKS tried to schedule an extra worker with 2560Mi memory and 500m CPU requests. The eligible pools had no room for the surge pod, leaving the rollout stuck with the new pod pending and the old pod still running.

The service worker is an async queue consumer, so replacing it in place is a better default than reserving extra surge capacity for every update.

Branch Coverage

• Base: main
• Head: 3a607d5
• Reviewed: 1 commit, 1 Helm template file, 5 inserted lines
• Changed: helm/codeapi/templates/worker-sandbox-deployment.yaml

Verification

Current head:

• helm lint helm/codeapi -f /private/tmp/df-cloud-codeapi-stg-rollout/helm-charts/codeapi/stg/values.yaml -> passed
• helm template codeapi helm/codeapi -n codeapi -f /private/tmp/df-cloud-codeapi-stg-rollout/helm-charts/codeapi/stg/values.yaml --show-only templates/worker-sandbox-deployment.yaml -> rendered maxSurge: 0 and maxUnavailable: 1 on codeapi-service-worker
• git diff --check -> passed

Staging evidence behind this fix:

• codeapi-service-worker-6f865d45cb-b8gbl stayed pending because 0/11 nodes were schedulable: insufficient CPU or memory on eligible nodes, untolerated taints elsewhere, and relevant node groups at max size.

Blocking Before Merge

None.