fix(release): actually build the arm64 binary it packages

The first release attempt failed at packaging:

  cp: cannot stat 'target/aarch64-unknown-linux-gnu/release/runicgateway-installer':
      No such file or directory

installer#10 added linux-aarch64 in three of the four places it belongs — the
rustup target, the `cp` into dist/, and the SHA256SUMS line — but never added a
build step for it. Nothing ever produced the binary, so the run got all the way
to packaging before noticing. No tag or release was created, so a retry is clean.

Two changes:

- Build arm64, with the same linker/CC/AR env pattern the Windows cross build
  already uses.
- Name `libc6-dev-arm64-cross` in the apt install. gcc-aarch64-linux-gnu only
  *recommends* it and this step runs --no-install-recommends, so without it the
  Rust half builds and then `ring` (under ureq's rustls) dies compiling C on a
  missing bits/libc-header-start.h.

Verified by reproducing CI in rust:1-slim-bookworm — the same apt line including
--no-install-recommends, then the same cargo invocation. Builds clean and emits
a 4.6 MB binary at exactly the path the packaging step reads.

Co-Authored-By: Claude <noreply@anthropic.com>

.gitea/workflows/release.yml

@@ -247,8 +247,13 @@ jobs:
           set -euo pipefail
           SUDO=""; [ "$(id -u)" -ne 0 ] && SUDO="sudo"
           $SUDO apt-get update
+          # libc6-dev-arm64-cross is named explicitly on purpose: gcc-aarch64-linux-gnu only
+          # *recommends* it, and this install runs --no-install-recommends. Without it the Rust
+          # half of the arm64 build succeeds and then `ring` (under ureq's rustls) dies compiling
+          # C, on a missing bits/libc-header-start.h.
           $SUDO apt-get install -y --no-install-recommends \
-            build-essential gcc-mingw-w64-x86-64 curl ca-certificates git jq
+            build-essential gcc-mingw-w64-x86-64 gcc-aarch64-linux-gnu libc6-dev-arm64-cross \
+            curl ca-certificates git jq
 
           if ! command -v cargo >/dev/null 2>&1; then
             curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs \
@@ -296,6 +301,18 @@ jobs:
           AR_x86_64_pc_windows_gnu: x86_64-w64-mingw32-ar
         run: cargo build --release --locked --target "${WINDOWS_TARGET}"
 
+      # The installer has to run wherever the sidecar it installs can run, and link publishes an
+      # arm64 Linux binary (PLAN.md §5.2). Without this step the target is installed and the
+      # artifact is packaged, but nothing ever builds it — which is exactly how the first release
+      # attempt failed, at `cp: cannot stat target/aarch64-unknown-linux-gnu/release/...`.
+      - name: cargo build --release (Linux arm64, cross)
+        if: ${{ steps.plan.outputs.release == 'true' }}
+        env:
+          CARGO_TARGET_AARCH64_UNKNOWN_LINUX_GNU_LINKER: aarch64-linux-gnu-gcc
+          CC_aarch64_unknown_linux_gnu: aarch64-linux-gnu-gcc
+          AR_aarch64_unknown_linux_gnu: aarch64-linux-gnu-ar
+        run: cargo build --release --locked --target "${ARM64_TARGET}"
+
       # ── RUST ADAPTER: package artifacts (+ checksums) ────────────────────
       # SHA256SUMS is the trust anchor for these unsigned binaries (PLAN.md §3),
       # so it ships with every release and the docs lead with the verify command.