ci: swap artifact upload to the mirrored action (issue 2270)

Both desktop upload steps used actions/upload-artifact@v3, which reports
success while Gitea stores the result in a format its v4-only artifact API
will never serve back — 110 artifacts on this repo are on disk, have valid
DB rows, and are invisible to the REST API, the web download route and the
MCP tools alike. Green jobs producing nothing retrievable.

Point both at bvandeusen/upload-artifact (pull mirror of the Forgejo
project's fork, GHES refusal disabled), pinned by SHA because the mirror
auto-syncs. Not actions/upload-artifact@v4: its isGhes() throws on the
hostname before opening a connection, so no server-side change reaches it.

Also drop continue-on-error and set if-no-files-found: error on both steps.
Between them, a failed or empty upload was reported as a green run — the
same silence that let this go unnoticed for a month.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

ci-requirements.md

@@ -45,6 +45,33 @@ entirely on `ci-python:3.14`.
   (family rule 46).
 - The production runtime `Dockerfile` tracks python:3.12 so test results stay
   representative of the deployed image.
+- **Artifacts — use the mirrored upload action, never `actions/upload-artifact`.**
+  ```yaml
+  uses: https://git.fabledsword.com/bvandeusen/upload-artifact@cb8afe72b42edc798abfb8fcb556cf660d894245
+  ```
+  Upstream's `actions/upload-artifact@v4` cannot work against this instance and
+  no server-side change will help: its `isGhes()` rejects any hostname that isn't
+  `github.com` / `*.ghe.com` / `*.localhost` and throws before it opens a
+  connection, so the server is never asked what it supports. `@v3` is worse — it
+  reports success, and Gitea then serves artifacts back only through the v4 API
+  (`content_encoding = application/zip`), so a v3 upload is stored but invisible
+  to every retrieval path. A green job producing nothing retrievable.
+
+  `bvandeusen/upload-artifact` is our pull mirror of `forgejo/upload-artifact`
+  (the Forgejo project's fork, one commit on upstream v5.0.0 disabling that
+  check). Mirrored so CI depends on a commit we hold; pinned by SHA because the
+  mirror auto-syncs and a moved upstream tag would otherwise change what runs.
+
+  Both desktop upload steps also set `if-no-files-found: error` and carry **no**
+  `continue-on-error`. They previously had both defaults inverted, which is how
+  110 unreachable artifacts accumulated on this repo without anyone noticing —
+  the upload could fail or match nothing and the run still went green. Scribe
+  issues 2255 / 2270 have the full teardown.
+
+  Download: `GET /api/v1/repos/{owner}/{repo}/actions/runs/{run_id}/artifacts`
+  for the id (global run id, not the repo-scoped run number), then
+  `…/actions/artifacts/{id}/zip`. Note the workstation has no `unzip` — use
+  `python3 -m zipfile -e`.
 
 ## Desktop (Tauri) lane — separate workflow