ci: fetch the aarch64 musl toolchain from GitHub instead of musl.cc

[Shirofune-Security]

The release workflow cannot complete right now. upload (ubuntu-latest, aarch64-unknown-linux-musl) dies before it reaches cargo build:

curl: (28) Failed to connect to musl.cc port 443 after 136096 ms: Couldn't connect to server
gzip: stdin: unexpected end of file
tar: Child returned status 1
##[error]Process completed with exit code 2.

musl.cc is a single volunteer-run host with no CDN or SLA, and it has stopped answering — this is not a one-off blip; the step fails the same way on re-run. Because the matrix is fail-fast, that one job also cancels the other eight targets, and upload-all-platforms / all-packages-zip are then skipped, so the whole release is blocked.

Change

Fetch the toolchain from the cross-tools/musl-cross GitHub release instead. It publishes aarch64-unknown-linux-musl.tar.xz built from the same musl-cross-make recipe, and GitHub Releases are already a hard dependency of this workflow — so this adds no new point of failure rather than trading one flaky host for another.

The tool prefix differs between the two builds (aarch64-unknown-linux-musl-gcc vs. musl.cc's aarch64-linux-musl-gcc), so CC/CXX/AR, the $GITHUB_PATH entry and the linker in .cargo/config.toml are updated to match. The reasoning in the existing comment is kept: this still has to be a real musl cross toolchain, because linking with the glibc gcc-aarch64-linux-gnu produces a binary killed at startup (#1332).

Hardened the fetch while touching it:

• -f so an HTTP error page can never be piped in as if it were the archive (the old -sSL had no -f).
• --retry 5 --retry-all-errors --retry-delay 5 --connect-timeout 30 to ride out a transient blip instead of failing a release on one bad request.
• Download to a file, then extract. The old curl | tar turned a network failure into gzip: stdin: unexpected end of file, which reads like archive corruption rather than "the host is down".
• Pinned sha256. This toolchain compiles and links a binary we publish, so it is worth verifying rather than trusting whatever an unpinned URL returns.

Also set fail-fast: false on the upload matrix. upload-all-platforms needs every target anyway, so cancelling the survivors buys nothing and costs a full re-run just to learn whether the other eight were fine.

Verification

Checked against the real artifact rather than assumed:

• the pinned sha256 (90282c46…) matches the published aarch64-unknown-linux-musl.tar.xz.sha256;
• extracting it produces $HOME/aarch64-unknown-linux-musl/bin/aarch64-unknown-linux-musl-{gcc,g++,ar,ranlib,strip}, exactly the paths and names the step now references;
• the workflow YAML parses, and the matrix still lists all nine targets.

The toolchain binaries are x86_64-hosted, which is right for ubuntu-latest but means the cross-build itself can only be exercised on the runner — worth watching that job on the next release run.