fix: update v7.5.4453 Docker Compose image manifests

[DaedalusG]

Summary

• update both release-managed Docker Compose manifests to public Sourcegraph 7.5.4453 images
• pin each image to its promoted digest
• repair the release-v7.5.4453 branch before moving tag v7.5.4453 to the corrected branch head

Impact

The current v7.5.4453 tag contains stale Docker Compose image references, including Sourcegraph 6.1 and PostgreSQL 6.0 images. Users checking out the 7.5.4453 tag therefore do not receive the images produced for the 7.5.4453 search release.

What happened

The Temporal UpdateDockerImages activity completed successfully and reported both expected files as updated. It created commit d20cc5d6f1da12a6872fa968b9f927c18cc904c6 (Update compose images to v7.5.4453). That commit contains the expected internal image changes, but it is no longer reachable from the release branch.

One second later, the workflow created the empty Buildkite configuration commit 7e757fd508c04ea857580b1438c7108602eaca2d. Both commits have the same parent, 31be4b977b9b9c28f9ccc4a4a2a188a972ab0f54, rather than the configuration commit having the image-update commit as its parent:

31be4b
├── d20cc5d  Update compose images to v7.5.4453 (orphaned)
└── 7e757fd  release: v7.5.4453                 (branch head)

Our hypothesis is that the GitHub ref read performed by the configuration-commit activity briefly returned the old branch head after the image activity had updated it. The configuration commit was consequently created from the stale parent. The workflow then force-updated the branch ref, replacing the image commit instead of advancing from it.

This matches the implementation: the generic commit input supports an explicit ParentCommitSHA to avoid GitHub eventual-consistency races, but the empty configuration-commit path fetches the branch head again and does not chain directly from the image activity result. The ref update is also forced, allowing a stale, non-fast-forward commit to silently replace the previous branch head.

This would explain why prior releases worked: the race depends on whether the updated GitHub ref is visible before the immediately following activity reads it. The k8s workflow performs multiple commits and has more time between its first update and configuration commit.

Follow-up

After this PR merges, move tag v7.5.4453 to the merged release-v7.5.4453 branch head so checkouts of the tag receive these corrected manifests.

The workflow should separately be hardened by explicitly chaining the configuration commit from the image-update commit and avoiding forced ref updates for normal sequential commits.

Test plan

• verified the PR changes only the two manifests processed by UpdateDockerImages
• verified all Sourcegraph image references use tag 7.5.4453 and pinned public digests
• verified the promoted digests against the k8s release manifests; verified the caddy digest directly against Docker Hub
• ran git diff --check