ci(bump): gate toolchain install behind a cheap version check; fix binpkg verify (#4)

## Why

The daily **Bump** job (`runs/107` and every other scheduled run) does ~5–26 min
of work on every run before it ever checks whether a bump is needed — and on the
common no-op day it isn't. Timeline of a no-op run:

`docker pull stage3` → `emerge-webrsync` → **`emerge … dev-lang/go dev-util/pkgdev` (29 pkgs)** → `bump-version.sh` finds `already at latest` and exits in **1 second**.

`go`/`pkgdev`/`xz`/`jq` are only needed when a bump actually happens. Recent
no-op scheduled runs took 5m, 26m, 9m, 5m, 10m — all to do nothing.

Separately, the log on every emerge was flooded with binpkg GPG failures
(`unknown key`, `pubring.kbx: No such file`, `Try running getuto`). The
`sed 's/^verify-signature = true/.../'` matched nothing in the stage3 binhost
config, so the intended "disable binpkg signature verification" never took
effect (it worked anyway only because the failures are non-fatal).

## What

- **`bump.yaml`**: add a cheap `Check whether a bump is needed` step that compares
  the newest upstream release (`releases.rss`) against the newest committed ebuild
  (Gitea contents API) using only base-image `wget`, and gate `Sync ::gentoo`,
  the toolchain install, and the bump step on its `needed` output. The gate only
  short-circuits when **confident** (both versions parsed and current ≥ upstream);
  on any doubt — failed fetch, unparseable version — it falls through to the full
  run, where `bump-version.sh` remains the source of truth and re-checks.
- **`bump.yaml` + `ci.yaml`**: replace the no-op `sed` with `sed -i '/^verify-signature/d'`
  + append `verify-signature = false`, so the knob is actually set regardless of
  the stage3 default contents.

## Notes / limits

- The job `container:` still pulls `gentoo/stage3` before the gate runs, so the
  ~3.5 min image pull on no-op days is unchanged; this saves the larger
  webrsync + 29-package emerge. A follow-up could split the gate into a separate
  container-less job to skip the pull too, but that depends on what the runner
  maps `runs-on: ubuntu-latest` to, so it's left out here.
- Validated: `yamllint -c .yamllint.yaml` clean on both files; version-comparison
  logic and the contents-API JSON parsing unit-tested locally (equal / upstream-newer /
  current-ahead / parse-failure cases).

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Reviewed-on: #4
Co-authored-by: Ali Zein Yousuf <azy5030@gmail.com>
Co-committed-by: Ali Zein Yousuf <azy5030@gmail.com>

.gitea/workflows/ci.yaml

@@ -2,7 +2,43 @@ name: CI
 on: [push]
 
 jobs:
+  # Lint gate: runs on the plain Docker-backend runner (not the Gentoo
+  # container) and must pass before the build job starts. Mirrors the lint job
+  # in the homeserver repo; `just lint` runs markdownlint/shellcheck/yamllint/
+  # actionlint over the repo.
+  lint:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      # setup-just fetches its binary from GitHub; on a Gitea runner the default
+      # github-token is the *Gitea* token (GitHub rejects it 401), so pass none
+      # and use GitHub's unauthenticated API.
+      - uses: extractions/setup-just@v4
+        with:
+          github-token: ""
+
+      - uses: taiki-e/install-action@v2
+        env:
+          GITHUB_TOKEN: ""
+        with:
+          tool: shellcheck
+
+      - name: Install markdownlint-cli
+        run: npm install -g markdownlint-cli
+
+      # actionlint has no maintained setup-action and uv ships via astral.sh;
+      # both installers hit their own release assets (no GitHub token needed).
+      - name: Install yamllint + actionlint tooling
+        run: |
+          curl -LsSf https://astral.sh/uv/install.sh | env UV_INSTALL_DIR=/usr/local/bin sh
+          bash <(curl -fsSL https://raw.githubusercontent.com/rhysd/actionlint/main/scripts/download-actionlint.bash) latest /usr/local/bin
+
+      - name: Run linters
+        run: just lint
+
   build:
+    needs: lint
     # The label only schedules the job on the (Docker-backend) runner; the steps
     # actually run inside the Gentoo container declared below.
     runs-on: ubuntu-latest
@@ -22,12 +58,16 @@ jobs:
           mkdir -p /etc/portage/repos.conf
           printf '[DEFAULT]\nmain-repo = gentoo\n\n[gentoo]\nlocation = /var/db/repos/gentoo\n' \
             > /etc/portage/repos.conf/gentoo.conf
-          sed -i 's/^verify-signature = true/verify-signature = false/' \
-            /etc/portage/binrepos.conf/gentoo.conf
+          sed -i '/^verify-signature/d' /etc/portage/binrepos.conf/gentoo.conf
+          printf '\nverify-signature = false\n' >> /etc/portage/binrepos.conf/gentoo.conf
           emerge -q --getbinpkg net-misc/curl dev-util/pkgcheck
 
-      # Place this overlay at /var/db/repos/azy5030. actions/checkout is avoided
-      # (SHA-256 Gitea repos break it); curl + tar fetches the source archive.
+      # Place this overlay at /var/db/repos/azy5030 via curl + tar. actions/checkout
+      # can't run here: this job uses the gentoo/stage3 container, and the Gitea
+      # runner executes JS actions with `node` *inside* that container
+      # (`docker exec node …`) — stage3 ships no node, so checkout fails with
+      # exit 127. (The lint job uses actions/checkout fine: it has no container:
+      # and runs in the runner's default node-capable image.)
       - name: Check out overlay
         env:
           TOKEN: ${{ github.token }}