ci(deploy): keep deploy jobs on fedora-43 (ssh is present via git-core)

Reverts the move to `infra`. Verified on a fedora-43 runner that the ssh
reachability check ran fine (it added the host key and connected) — the
earlier deploy failure was the unprovisioned remote sudo step, not a missing
ssh client. Every runner has ssh: `git` (installed for checkout) pulls
`git-core`, which hard-requires `openssh-clients`. So fedora-43 (ssh + rsync +
curl) is the right, lighter runner for these deploy jobs.

See architecture gitea-runners.md.

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

.gitea/workflows/deploy.yml

@@ -8,8 +8,8 @@
 #   web (SPA)     -> oolon.kosherinata.internal           (nginx serves + proxies /v1)
 #
 # Runners (see architecture gitea-runners.md): Rust build on `rust` (cargo toolchain);
-# SPA build on `fedora-43` (node + pnpm); deploy jobs on `infra` (the only general image
-# with an ssh client + rsync). The whole fleet is Fedora, so binaries are built native —
+# SPA build + deploy jobs on `fedora-43` (node + pnpm; ssh via git-core's openssh-clients
+# dep; rsync + curl in the base). The whole fleet is Fedora, so binaries are built native —
 # no glibc skew, no musl toolchain needed (deployment-gitea-actions.md §6: build on a
 # runner no newer than the oldest target).
 #
@@ -70,7 +70,7 @@ jobs:
 
   deploy-api:
     needs: build-api
-    runs-on: infra
+    runs-on: fedora-43
     steps:
       - uses: actions/checkout@v4
       - uses: actions/download-artifact@v3
@@ -128,7 +128,7 @@ jobs:
 
   deploy-web:
     needs: build-web
-    runs-on: infra
+    runs-on: fedora-43
     steps:
       - uses: actions/download-artifact@v3
         with: