ci: run the build on the rust runner, drop corepack, pin the site check to loopback

Three things that would each have failed the run seconds in
(architecture/gitea-runners.md §4):

- `runs-on: fedora-43` for a cargo build is `cargo: command not found` — the
  fedora images are node/shell runners with no Rust. `rust` is built on
  `runner-fedora-44`, so it carries node + pnpm as well and one job still builds
  both halves. musl stays: that runner is Fedora 44 and the targets are 43.
- `corepack enable` is not bundled by any image and pnpm is already on PATH.
- The site check curled the public name *from the edge proxy*, where it resolves
  to the site WAN address and dead-ends on the OPNsense LAN interface. Pinned to
  loopback, which still exercises the stream router, SNI, the vhost, the
  cross-site hop and the API.

Deploy jobs stay on `infra`: §4 is about tooling, not routing, and these targets
are mesh-only .internal names — same reasoning as lair/quantus and lair/mail.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MSDYiibCtELsrjQq6KXnoi

.gitea/workflows/deploy.yaml

@@ -37,7 +37,11 @@ env:
 
 jobs:
   build:
-    runs-on: fedora-43
+    # `rust`, not `fedora-43`: the fedora images are node/shell runners with no
+    # cargo at all (gitea-runners.md §4). `runner-rust` is built on
+    # `runner-fedora-44`, so it carries node + pnpm too and one job can build
+    # both halves.
+    runs-on: rust
     steps:
       - uses: actions/checkout@v4
 
@@ -59,9 +63,10 @@ jobs:
           SQLX_OFFLINE: "true"
         run: |
           set -euo pipefail
-          # musl, statically linked: the runner image is newer than the target
-          # host, and a glibc-linked binary built here would not load there
-          # (deployment-gitea-actions.md §6).
+          # musl, statically linked. gitea-runners.md §4 notes a native build is
+          # simpler when the runner matches the target fleet — it does not here:
+          # `runner-rust` is Fedora 44 and the targets are Fedora 43, so a
+          # glibc-linked binary built here would not load there.
           cargo build --release --target x86_64-unknown-linux-musl \
             -p blackbeard-api -p blackbeard-cli
           file target/x86_64-unknown-linux-musl/release/blackbeard-api
@@ -82,7 +87,8 @@ jobs:
       - name: build web
         run: |
           set -euo pipefail
-          corepack enable
+          # No `corepack enable`: no runner image bundles it, and pnpm is
+          # already on PATH from `npm i -g pnpm` (gitea-runners.md §4).
           cd web
           pnpm install --frozen-lockfile
           pnpm lint
@@ -326,7 +332,12 @@ jobs:
         # chain list is a broken deploy that a status code alone would pass.
         run: |
           set -euo pipefail
-          ssh "$EDGE_HOST" "curl -sf --max-time 15 https://$PUBLIC_NAME/v1/chains" > chains.json
+          # --resolve to loopback: from inside the mesh the public name resolves
+          # to the site's WAN address and dead-ends on the OPNsense LAN
+          # interface (reverse-proxies.md §2). Pinning it to 127.0.0.1 still
+          # exercises the real path — the :443 stream router, SNI, the vhost,
+          # the cross-site hop and the API — just without leaving the host.
+          ssh "$EDGE_HOST" "curl -sf --max-time 20 --resolve $PUBLIC_NAME:443:127.0.0.1 https://$PUBLIC_NAME/v1/chains" > chains.json
           python3 - <<'PY'
           import json, sys
           chains = json.load(open("chains.json"))