Pin third-party actions to SHAs and scope workflow tokens - #413

upload-artifact and download-artifact are a matched pair in release.yml:
the build job uploads the signed, notarized binary and the release job
downloads exactly that artifact to attach it to the release.

Dependabot raised only the upload half, because open-pull-requests-limit
was already saturated by the other actions updates. Merging that alone
would have left upload at v7 and download at v4 — a mismatch the release
dry run cannot catch, since the release job only runs on a tag push. Both
halves now move together.

Verified the merge preserves the SHA pinning from #413: SonarCloud
reported the third-party actions as unpinned, but that was an artifact of
analysing a branch nine commits behind main. A test merge confirmed all
five third-party pins survive, and that setup-xcode's SHA was correctly
re-pinned by Dependabot when it bumped to 1.7.0.

Closes #385.

The workflow could not run, in three independent ways:

- devbotsxyz/[email protected] no longer exists — the repository returns
  404. Found while SHA-pinning actions in #413; it was the one action that
  could not be pinned.
- `swift run xchtmlreport -- -j ...` exits 64: SwiftPM forwards the --, so
  -j parses as a result-bundle path rather than the JUnit flag.
- It downloaded sample-test-results-macos-12-14.2, an artifact name
  test-artifacts.yml no longer produces.

Nothing is lost: the Pages site returns HTTP 404 and has never served
content. The only deployment attempts were three, all on 2023-05-15.

Closes #405 and #406 as moot — both only touched this file.

The repository still has Pages enabled in settings, now with no workflow
behind it. That can be switched off in repository settings if wanted;
a pull request should not change repository settings silently.

…tion (#427)

* Publish releases with the runner's gh CLI instead of an action

The release job is the most sensitive path in the repository: it holds the
Developer ID signing identity, the notarization credentials and a token with
contents: write. Until now it also handed all of that to a third-party action
to do something the runner can already do. zizmor flags it as superfluous and
CodeRabbit raised it on #413.

`gh release create` covers every input the action was given, and the resulting
release is identical in shape: --generate-notes sets both the body and the
title, and GitHub's generate-notes API returns the tag as the name, which is
what the action produced for 3.0.0rc1 and 3.0.0. Neither sends make_latest, so
GitHub's default still applies. Neither drafts.

Two things are deliberately stricter than what they replace. --verify-tag stops
gh from inventing a tag off the default branch if the one it is handed does not
exist; the tag is what triggered the run, so that could only mean something had
gone wrong. And a glob that matches nothing now fails the step, where the action
would happily have published a release with no binary attached to it.

Everything reaches the script through the environment rather than being
interpolated into it, and GH_REPO is set because this job has no checkout for
gh to infer the repository from.

Refs #414

* Record why a re-run over an existing release is meant to fail

Raised by CodeRabbit on #427. The old action would have replaced the assets
of an already-published release; gh refuses. On a path that publishes signed,
notarized binaries that is the behaviour we want, so it is worth writing down
before someone reads the difference as a regression and adds a fallback.