fix(release-image): space multi-image promotions so their webhooks cannot race

[cshuttle]

Summary

A release that promotes two images tags them in the same second. ghcr fires one package webhook per tag, argocd-image-updater handles each in its own clone → commit → push against the same GitOps repo, and the loser is rejected:

! [remote rejected] main -> main (cannot lock ref 'refs/heads/main': is at 10496b0 but expected d220f45)

It is not retried, so that image's pin stays on the previous version until the 30-minute poll repairs it (cshuttle/main#244, and the reasoning in apps/argocd/image-updater/image-updater-serialize-patch.yaml). VirtualWindow has hit it on four of its last five releases; Atlas hit it twice in one day.

• New tag-spacing-seconds input, default 60: the promote loop waits that long between images (no wait before the first, none for a single-image release).
• A clone + commit + push takes a couple of seconds, so a minute is ample, and the cost is one wait on a release that already runs for minutes.
• Repos whose images no bot watches can pass tag-spacing-seconds: 0.

Nothing else changes: images are still promoted by digest, in the same order, with the same verification.

Tests

• The file parses (yaml.safe_load), and the input default reads back as 60.
• No caller needs a change; the default applies.

🤖 Generated with Claude Code