Retry update_kubernetes_deployment push on concurrent-push race

[Christdej]

Summary

• Two or more callers of update_kubernetes_deployment.yml hitting the same infrastructure repo main at once race on git push — one wins, the rest fail with a non-fast-forward reject and require a manual rerun. Observed as a flake on sara-timeseries deploy_to_development after the SARA promote fanned out multiple tag bumps against analytics-infrastructure main.
• Wraps the tag-edit + commit + push sequence in a retry loop (up to 5 attempts, linear back-off). Each attempt starts with git fetch origin main && git reset --hard origin/main, re-applies the sed, commits, and pushes. If another job's commit landed in between, the reset picks it up and we replay on top; the sed is idempotent so no data is lost.
• Merges the previous two-step (Update image tag in kustomization + Commit and push changes) into a single step so the retry envelops both. Explicit git push origin HEAD:main to keep the refspec unambiguous.
• Preserves the existing early-exit when the tag is already up to date (avoids empty commits when a peer job pushed the same tag first).

Behaviour

• Happy path: identical — one fetch, one commit, one push.
• Race path: previously would fail the job; now transparently re-syncs, replays the edit, and pushes on the next attempt.
• Hard failure (5 consecutive rejections): fails the job with a clear message rather than silently masking a real conflict.

Test plan

• Static: sed/grep logic unchanged; only the surrounding control flow moved.
• Runtime: next SARA promote or any parallel deploy_to_development fan-out will exercise it. Since this workflow is workflow_call-only, no additional trigger wiring needed.

[Christdej]

Closing for now — the concurrent-push race has only been observed once so far. Will reopen (or recreate) if the flake recurs.