Realign the release branch on its remote during checkout

`checkout-release-branch.sh` fetched the release branch then checked it out, but never moved the local branch to the fetched commit. Buildkite cleans the working copy between jobs, yet can reuse it — so a `refs/heads/release/x.y` left behind by an earlier job on the same agent survives, and `git checkout` then just switches to that stale local ref instead of the freshly fetched remote one. Anything running afterwards, such as the version bump and the GitHub Release draft created by `finalize_release`, would target the wrong commit.

Adding `git reset --hard "origin/$BRANCH_NAME"` after the checkout makes the branch match the remote unconditionally. `reset --hard` rather than `git pull`: it needs no extra network round trip and cannot produce a merge if the local and remote refs have diverged.

This is the second part of AINFRA-2725, a follow-up to the WooCommerce iOS 25.1 release incident.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: AliSoftware

.buildkite/commands/checkout-release-branch.sh

@@ -10,3 +10,6 @@ fi
 BRANCH_NAME="release/${RELEASE_VERSION}"
 git fetch origin "$BRANCH_NAME"
 git checkout "$BRANCH_NAME"
+# Buildkite can reuse a working copy where "$BRANCH_NAME" was left at an older commit by a previous job,
+# so realign it on the remote. `reset --hard` rather than `git pull`, to avoid merging if the two diverged.
+git reset --hard "origin/$BRANCH_NAME"