When the MSYS2-runtime version changed recently, the `msys-2.0.dll`
contents of the minimal SDK diverged from the contents of the same file
in the Git for Windows installation in `C:\Program Files`.

Since we adjust the `PATH` before caching, that matters because the
`gzip` executable that is found in the `PATH` by `tar -z` is the version
from the minimal SDK, which therefore insists on using the MSYS2 runtime
from the minimal SDK, while the `tar` executable used by @actions/cache
is the `C:\Program Files\Git\usr\bin\tar.exe` one and hence uses a
potentially-incompatible MSYS2 runtime version of the Git for Windows
installation.

In git-for-windows/msys2-runtime#48, we tried to
address this by teaching the MSYS2 runtime to avoid talking to a
different MSYS2 runtime version. But the indicator used in that Pull
Request is the version of the _Cygwin_ runtime on which it is based.
Which means that Git for Windows-only changes in the MSYS2 runtime are
not reflected in that indicator, and the MSYS2 runtime _still_ tries to
talk to the other version, and the only symptom the user gets is a terse
`Child returned status 127`.

Let's work around this here (taking the pressure off fixing the MSYS2
runtime logic) simply by adjusting the `PATH` only _after_ letting
@actions/cache do its thing.

Signed-off-by: Johannes Schindelin <[email protected]>

We need this tool for pushing (to be precise, to generate the
authorization header).

For the same reason as explained in 8d36b48 (open-pr: avoid caching
error 127, 2023-02-21) where the interplay of two incompatible MSYS2
runtime versions would cause an unhelpful exit code 127, calling Git for
Windows' `base64.exe` from the SDK subset's Bash should be avoided.

Signed-off-by: Johannes Schindelin <[email protected]>