Use stable Git for Windows in test-fixtures-windows

Now that Git for Windows 2.49.0 has a stable release, this changes
the upgrade step that was added to `test-fixtures-windows` in
4237e5a (#1870), so that it downloads an installer from the release
marked as "latest", rather than the release that has the newest
tag. The release marked "latest" is usually a stable release in
projects that have any stable releases, and in particular it is a
stable release in Git for Windows.

This is *not* needed to switch from the release candidate to the
stable release for 2.49.0. The download logic already in place
currently gets the stable release automatically, because it is the
newest tag.

Nonetheless, there are three reasons to prefer the "latest" tag to
get the stable release, now that the stable release is available.
In descending order of significance, they are:

- We upgrade to work around #1849, for which 2.49.0 is preferable
  to 2.48.1 (which the Windows runner images currently have).
  Continuing to take the newest tag will eventually take a
  pre-release for the next version. That would probably work, but
  it is not currently a goal.

  There is sometimes a delay between when a stable release of Git
  for Windows comes out and when the stable runner images are
  released with it. (Pre-release runner images exist, but they are
  not run on GitHub-hosted runners.) So even assuming this upgrade
  step is to be removed once it is no longer needed, it could
  easily end up remaining long enough for a new Git for Windows
  pre-release to come out.

- An update may potentially be released for an earlier minor
  version (y in x.y.z), in which case the tag for it would be
  newer and we would downgrade instead. Now that the release
  marked "latest" is usable here, we can use it and avoid that.

- If we decide to eventually deliberately test pre-releases, the
  step added in #1849 would probably not be usable in that form,
  because it could take either the next pre-release or a patch to
  an ealier release per the above points, and also for the separate
  reason that this CI job is not necessarily where we would want to
  test that.

  (As one example, there is currently no CI testing of the Git for
  Windows SDK, even though supporting it, in general and for
  running the test suite, is an explicit goal discussed in #1758,
  #1761, #1862, and #1864. If that is added, it may be a more
  opportune way to test prereleases.)

Author: EliahKagan

.github/workflows/ci.yml

@@ -191,7 +191,7 @@ jobs:
     runs-on: windows-latest
 
     steps:
-      - name: Upgrade Git for Windows to latest (pre)release
+      - name: Upgrade Git for Windows to latest stable release
         # This upgrades Git to work around https://github.com/GitoxideLabs/gitoxide/issues/1849.
         # TODO: Remove this step once the runner image has Git 2.49.0 or higher.
         env:
@@ -214,8 +214,7 @@ jobs:
 
           mkdir $workingDir | Out-Null
           cd $workingDir
-          $newestTag = gh release list --repo $repo --limit 1 --json tagName --jq '.[0].tagName'
-          gh release download $newestTag --repo $repo --pattern $pattern
+          gh release download --repo $repo --pattern $pattern
           $installer = Get-Item $pattern
           Start-Process -FilePath $installer -ArgumentList $arguments -NoNewWindow -Wait