fix(ci): stop telling readers the runner can't run upload-artifact@v4+

build.yml and baseline.yml both explained a missing artifact step by
saying act_runner cannot run actions/upload-artifact@v4+ (and baseline.yml
said ci-requirements.md records that, which it does not). The runner is
now gitea/runner 3.x, which edits the action's GHES refusal out of its
bundle, and stock v4+ is proven working on this forge (Scribe spike #3843).

Comments only. Neither lane gains an upload step: build-web still reads
the signed XPI from the release asset, and the baseline candidate is
still printed to the log, because those remain the better channels. The
comments now say why for the right reason.

Scribe snippet #2271, milestone 395.

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

.forgejo/workflows/baseline.yml

@@ -172,10 +172,11 @@ jobs:
           mkdir -p /tmp/versions_held
           mv alembic/versions/*.py /tmp/versions_held/ 2>/dev/null || true
           DB_NAME=fc_gen alembic revision --autogenerate -m "baseline" || true
-          # Printed rather than uploaded: ci-requirements.md records that this
-          # runner cannot do actions/upload-artifact@v4+, and the repo dropped
-          # the action entirely in 2026-05, so the job log is the retrieval
-          # channel actually proven here.
+          # Printed rather than uploaded: the repo dropped actions/upload-artifact
+          # in 2026-05, when the runner could not run v4+, and the job log is the
+          # retrieval channel this job has proven. (gitea/runner 3.x runs stock
+          # upload-artifact now — Scribe snippet #2271 — so an artifact is an
+          # option if the log ever stops being enough.)
           #
           # base64, not the raw file. A plain `cat` of the ~33KB candidate was
           # TRUNCATED MID-LINE by the runner on run 4964 — it stopped inside