fix: rollout restart to avoid stale pod spec on redeploying with manifests

[vigneshrajsb]

What

Adds a kubectl rollout restart after kubectl apply in the manifest deploy job.

Problem

When redeploying a manifest service (e.g. after nuking and recreating a dependency like a database), kubectl apply is a no-op at the pod level if the pod template spec hasn't changed — same image, same env vars. Kubernetes sees the existing ReplicaSet already satisfies the desired state and skips pod replacement entirely.

This is a problem when the pod template is unchanged but a dependency has changed — specifically, init containers that seed or migrate a database never re-run because no new pod is ever created.

Fix

After kubectl apply, if the deployment exists, unconditionally run kubectl rollout restart before waiting on kubectl rollout status. This patches the restartedAt annotation on the pod template, guaranteeing new pods are always created and init containers always execute on every manifest deploy.

If the pod template spec did change (new image, new env), this results in a second rolling update — harmless, just slightly redundant.

Test plan

• Redeploy a manifest service where the pod template is unchanged — verify new pods are created and init container runs
• Redeploy a manifest service where the image changed — verify rollout still completes successfully (no double-failure)