docs(gitea-runners): correct ssh availability — every runner has it

Empirically verified (run on a fedora-43 runner): the ssh client is present
on every runner image, not just `infra`. The bare fedora/ubuntu container base
ships no ssh and weak deps are disabled, but each image installs `git` for
checkout, and `git-core` hard-requires `openssh-clients` — so ssh is pulled in
regardless. rsync + curl are likewise in every base.

Corrects the earlier claim that CI-driven deploy needs `infra`: deploy jobs
run fine on `fedora-43`. `infra`'s real payload is `stalwart-cli` / infra
service CLIs. Also notes that runner-infra's own Containerfile comment
("the ssh client is not in the base") is misleading.

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

gitea-runners.md

@@ -46,7 +46,7 @@ Image selection") for the full placement semantics.
 | `rust-gtk3` | `runner-rust-gtk3` | `runner-rust` | GTK3 stack: gtk3-devel, glib2/gdk-pixbuf2/pango-devel, webkit2gtk4.1-devel, libsoup3-devel, libappindicator-gtk3-devel (Tauri/GTK desktop builds) | 4 / 4 GiB |
 | `rpm` | `runner-rpm` | `runner-rust` | rpm-build, rpmdevtools, rpmlint, createrepo_c, copr-cli, rpm-sign, sequoia-sq, gnupg2, autotools, openssh-clients | 2 / 2 GiB |
 | `ffmpeg` | `runner-ffmpeg` | `runner-rust` | rpmfusion-free, ffmpeg-devel, clang (for `ffmpeg-sys`/`ac-ffmpeg`-style builds) | 4 / 4 GiB |
-| `infra` | `runner-infra` | `runner-fedora-44` | **openssh-clients + rsync + xz**, `stalwart-cli`. The home for infra deploy/reconcile tooling | 2 / 2 GiB |
+| `infra` | `runner-infra` | `runner-fedora-44` | `stalwart-cli` (+ xz for its tarballs). The home for infra service CLIs / IaC tooling | 2 / 2 GiB |
 | `cuda-13.0` | `runner-cuda-13.0` | `runner-fedora-43` | rustup stable (as `runner-rust`, inlined) **+ CUDA 13.0** (nvcc, cudart/nvrtc/cublas/cusparse/curand/cusolver-devel, cudnn9, nccl, cmake, ninja, gcc-c++) | 8 / 32 GiB |
 | `ubuntu-24.04` | `runner-ubuntu-24.04` | Ubuntu 24.04 | git, curl, jq, nodejs + npm + pnpm, rsync, python3-pip + `yq` | 2 / 2 GiB |
 | `deb` | `runner-deb` | `runner-rust-ubuntu` | Debian packaging: build-essential, debhelper, devscripts, dh-make, dpkg-dev, fakeroot, lintian, reprepro (+ apt `rustc`/`cargo` from the base) | 2 / 2 GiB |
@@ -60,6 +60,14 @@ Notes:
 - Every Fedora/Ubuntu base ships **`pnpm` installed globally via `npm install -g pnpm`**,
   **not** corepack — Fedora's/Ubuntu's `nodejs` rpm/deb does not bundle corepack. Call
   `pnpm` directly; do **not** `corepack enable` (see §4 gotchas).
+- **`ssh` + `rsync` are on every runner.** `rsync` is in each base's install list, and the
+  `git` every image installs (for `actions/checkout`) hard-requires `git-core`, which in
+  turn hard-requires `openssh-clients` — so the ssh client is present even though the bare
+  `fedora`/`ubuntu` container base doesn't ship it and weak deps are disabled. A CI-driven
+  deploy (ssh + rsync to targets) therefore runs fine on `fedora-43`/`fedora-44`; it does
+  **not** need `infra`. (`runner-infra`'s own Containerfile re-installs `openssh-clients`
+  belt-and-suspenders and its comment claiming "the ssh client is not in the base" is
+  misleading — it's pulled by git-core regardless.)
 - The **`rust`** toolchain is `rustup` stable, not Fedora's distro rustc, specifically so
   the `x86_64-unknown-linux-musl` std matches the compiler and static musl builds work.
 - `sccache` is installed on the Rust images but backing it with the shared S3 cache is
@@ -92,7 +100,8 @@ gcc 16. It re-inlines the rustup recipe rather than inheriting it.
 | --- | --- | --- |
 | `cargo build/test/clippy/fmt` | `rust` | the only images with a Rust toolchain (`rust`, `rpm`, `ffmpeg`, `rust-gtk3`, `cuda-13.0`); plain `fedora-*` have **no cargo** |
 | Build a Vite/React/npm/pnpm frontend | `fedora-43` / `fedora-44` | node + npm + **pnpm** preinstalled |
-| **Deploy over ssh + rsync** (CI-driven deploy) | `infra` | the **only** general image with an **ssh client**; the base `fedora-*` images have `rsync` but **not** `openssh-clients` |
+| **Deploy over ssh + rsync** (CI-driven deploy) | `fedora-43` / `fedora-44` | ssh (via git-core's `openssh-clients` dep) + rsync + curl are present on every runner |
+| Infra service admin (Stalwart mail, IaC CLIs) | `infra` | ships `stalwart-cli` and is the home for infra service tooling |
 | Build/sign RPMs, publish to COPR | `rpm` | rpmbuild, createrepo_c, copr-cli, signing |
 | Build `.deb`s | `deb` | debhelper/devscripts/reprepro |
 | CUDA / GPU-accelerated Rust (candle, flash-attn) | `cuda-13.0` | nvcc + CUDA dev libs; pinned to GPU hosts |
@@ -100,10 +109,11 @@ gcc 16. It re-inlines the rustup recipe rather than inheriting it.
 | GTK3 / Tauri desktop | `rust-gtk3` | GTK/webkit dev libs on top of Rust |
 | Plain shell / `jq` / `yq` / git plumbing | `fedora-43` / `fedora-44` / `ubuntu-24.04` | smallest images |
 
-**Multi-step deploys typically split across two runners:** a `rust` job to build the
+**Multi-step deploys commonly split across two runners** — a `rust` job to build + upload
-artifact + upload it, and an `infra` job (`needs:` the build) to ssh/rsync it to the
+the artifact, and a `fedora-43` job (`needs:` the build) to ssh/rsync it to the targets —
-targets. Don't try to do both on one runner — no single image has both cargo and an ssh
+mostly so the deploy job isn't billed the heavier `rust` image (4 CPU / 4 GiB) just to run
-client.
+ssh. This is a convenience, not a necessity: the `rust` runner also has git-core's ssh and
+rsync, so a single job could build and deploy if you prefer.
 
 ---
 
@@ -113,8 +123,11 @@ These are the traps that make a job fail seconds in with a "command not found":
 
 - **`runs-on: fedora-43` for a Rust build → `cargo: command not found`.** The `fedora-*`
   images are node/shell runners with no Rust. Use `rust`.
-- **`ssh`/`rsync-over-ssh` on `fedora-*` → `ssh: command not found`.** The base images ship
+- **Not a gotcha: ssh on `fedora-*`.** It's tempting to think the fedora runners lack an
-  `rsync` but not the ssh client. Deploy jobs go on `infra`.
+  ssh client (the bare container base doesn't ship one, and `runner-infra` re-installs
+  `openssh-clients` with a comment saying so). But every runner installs `git` for
+  checkout, and `git-core` hard-requires `openssh-clients` — so `ssh` is present on all of
+  them. Deploy on `fedora-43`; you do not need `infra` for ssh/rsync.
 - **`corepack enable` anywhere → fails / no-op.** No image bundles corepack; `pnpm` is
   already on `PATH` (installed via `npm i -g pnpm`). Just run `pnpm install` / `pnpm build`.
   A `packageManager` field in `package.json` is honoured for information but standalone
@@ -182,9 +195,9 @@ After a new/updated image is pushed and the manifest change is deployed (gongfoo
 ## 6. Checklist for a workflow author
 
 1. Match each job to a runner by what it *runs*, not by distro habit (§3). Rust → `rust`;
-   frontend → `fedora-*`; ssh/rsync deploy → `infra`.
+   frontend → `fedora-*`; ssh/rsync deploy → `fedora-43` (ssh + rsync are on every runner).
 2. Never install packages at run time. Missing tool → extend an image (§5).
 3. Don't `corepack enable`; call `pnpm` directly.
-4. Split build (`rust`) from deploy (`infra`) — no image has both cargo and ssh.
+4. Reserve `infra` for its actual payload (`stalwart-cli` / infra CLIs), not for ssh.
 5. If you add an image, register it in `gongfoo/asset/manifest.yml` with a minimal label
    set and sensible CPU/MEM.