Two concurrent release runs can race such that the older build's
image-deploy step finishes after the newer build already committed its
tag. Without an ordering check, last-writer-wins and the manifest
silently reverts to a stale image.
Add _monotonic_check: reads origin/main's current newTag for the image
and exits 0 (with a loud SKIP log) if it is numerically greater than the
tag we are trying to write. The guard runs before the kustomize edit and
again after each rebase in the push-retry loop, so both race shapes are
covered:
- Clone-then-lose: second clone already sees the newer tag → initial
guard fires before any commit.
- Concurrent-push: both cloned the same base; one pushes first; the
other rebases, then the post-rebase guard fires before the re-push.
Fixes bug-313bg8bgezp3
Before committing and pushing, query the Gitea API for open PRs in the
apps repo. If any open PR modifies the same kustomization.yaml path and
its diff contains the target tag, exit 0 — the PR is the intended review
gate and the direct push would bypass it.
Fails open on API errors so an outage does not block all deploys.
Fixes bug-nxhza9j2atqk