fix(ci): a deploy that was overtaken is not a deploy that failed #5606

"Verify deploy to production" went red for a deploy that worked perfectly.

Two merges landed 44 seconds apart, the second deploy overtook the first, and this job spent six minutes polling for a SHA production had already moved past. The commit was live the whole time — inside the one being served.

The premise was wrong, not the implementation

"Production must serve MY sha" holds only while merges are slower than deploys. Today's cadence broke that seven times over.

A red build for a condition that is not a failure is worse than no check: it's precisely what teaches people to ignore a red deploy, and it fires on every rapid merge sequence — exactly when someone is watching.

Now: if production serves a descendant of this commit, this commit shipped. git merge-base --is-ancestor answers that question and no other.

Verified against the real incident, not a mock

Using the two SHAs actually involved:

is-ancestor 4542595 20513ec  → true    (would now pass)
is-ancestor 20513ec 4542595  → false   (still fails)

The second line is the one that matters. This does not blanket-pass. If the update timer is genuinely stuck and production serves an older SHA, ours is not an ancestor of it and the job stays red — which is the case this check exists for.

The failure message now says which case it is, instead of assuming the timer.

One deliberate non-fatal path

The git fetch that makes the ancestry answerable can fail without failing the job — the loop falls through and keeps polling, which is exactly the behaviour this job had before. A degraded check, not a broken one.

That path matters more than it looks: once CI runs in an isolated job container with no /data/repos mount, origin won't be reachable, and this job needs to keep working rather than start lying in the other direction.