Work around a problem with a GCC upgrade in MSYS2

The MSYS2 project upgraded their GCC from v13.2 to v14.1, and that broke
Git's CI builds on Windows when building with `DEVELOPER=1` by virtue of
Git's CI builds using the `setup-git-for-windows-sdk` GitHub Action to
set up a minimal subset of Git for Windows' SDK to build Git, and this
GitHub Action picking up that GCC upgrade by mistake.

The mistake: The `ci-artifacts` workflow of `git-sdk-64` (which is
used as an indicator whether the revision can be used via the minimal
Git for Windows SDK in Git's CI builds) did _not_ test-build with
`DEVELOPER=1` until git-for-windows/git-sdk-64#83
was merged.

Let's specifically exclude the known-bad `git-sdk-64` revision (for
which the `ci-artifacts` workflow succeeded even when it should not
have) from being used in `setup-git-for-windows-sdk`.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Author: dscho

src/git.ts

@@ -107,6 +107,17 @@ export async function getViaGit(
       per_page: 1
     })
     head_sha = info.data.workflow_runs[0].head_sha
+    /*
+     * There was a GCC upgrade to v14.1 that broke the build with `DEVELOPER=1`,
+     * and `ci-artifacts` was not updated to test-build with `DEVELOPER=1` (this
+     * was fixed in https://github.com/git-for-windows/git-sdk-64/pull/83).
+     *
+     * Work around that by forcing the incorrectly-passing revision back to the
+     * last one before that GCC upgrade.
+     */
+    if (head_sha === '5f6ba092f690c0bbf84c7201be97db59cdaeb891') {
+      head_sha = 'e37e3f44c1934f0f263dabbf4ed50a3cfb6eaf71'
+    }
   } else {
     const info = await octokit.repos.getBranch({
       owner,