fix(ci/winget): forward GITHUB_REF_NAME into the remote shell

The catalogue-verify step has failed on every stable tag since it landed,
v0.20.0 included: `bash: line 6: GITHUB_REF_NAME: unbound variable`, twice,
then exit 1.

`env:` populates the RUNNER's environment. appleboy/ssh-action executes its
`script` on the REMOTE host over SSH, which inherits none of it — the action
has a separate `envs:` input naming the variables to forward. Without it the
`set -u` at the top of the script turns the first expansion into a fatal, and
the two `curl`s either side report only the collateral: `Failed writing body`
is curl losing its pipe when the `grep` it was feeding died.

The failure is maximally misleading, because everything it guards ALREADY
WORKED: the catalogue is built, tested and shipped in the preceding steps, and
only the proof-of-serving fails. Confirmed by hand against the live source
during the v0.20.0 release — it serves unom.PunktfunkHost 0.20.0 correctly.

The pattern was already right everywhere else: both "Pull and start docs" steps
(deploy-services.yml, docker.yml) pair `env:` with `envs:`. A sweep of the
other three ssh-action steps found no further instance — the remaining two pass
no variables at all.

.gitea/workflows/windows-host.yml

@@ -438,3 +438,9 @@ jobs:
             echo "winget source serving ${GITHUB_REF_NAME#v}"
         env:
           GITHUB_REF_NAME: ${{ gitea.ref_name }}
+        # `env:` populates the RUNNER's environment; this action runs `script` on the REMOTE
+        # host, which inherits nothing from it. `envs:` is the action's own allow-list of names
+        # to forward into the remote shell — without it `set -u` aborted at the first expansion
+        # ("GITHUB_REF_NAME: unbound variable") and the step failed on every tag, after the
+        # catalogue had already shipped correctly.
+        envs: GITHUB_REF_NAME