#9416 fix(ci): predict the promoted app digest instead of trusting a read right after the retag

Summary

• promote-app-image.sh decided whether the app deploy tag moved by reading the tag right after retagging it. That read can still return the previous image, so a moved tag was reported as unchanged. trigger-promote then checked the wrong pipeline execution: it refused to promote when a new execution had already started. If the read had lagged until before the execution started, it could instead have matched the previous execution and promoted Trigger.dev tasks before the app cut over
• The script now computes the digest the retag will push from imagetools create --dry-run before moving the tag. The dry run prints the exact manifest plus a trailing newline, so its hash is the pushed digest. After the move it waits up to a minute for the tag to resolve to that digest, failing loudly if it never does, then compares the predicted digest with the previous one

Type of Change

• Bug fix

Testing

• Against the registry: the dry-run hash of a real staging retag equals the digest the registry stored for that retag
• Script run in a Linux container with stubbed docker/aws: a stale read that catches up reports changed=true with the new digest; a genuinely unchanged retag reports changed=false; a tag that never resolves fails with exit 1; a first push with no previous tag reports changed=true
• The pre-fix script on the stale-read case reports changed=false with the previous digest, reproducing the failure
• bash -n

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing (new tests pass the test-audit authoring gate)
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)