ci: artifact uploads move to stock upload-artifact@v7

The Android APK upload and both desktop bundle uploads (Linux and
Windows) went through the bvandeusen fork mirror, with comments saying
stock upload-artifact throws GHESNotSupportedError on this hostname. That
stopped being true when the runner moved to gitea/runner 3.x, which
edits the refusal out of the action bundle; stock upload v4-v7 and
download v4-v8 were proven on 2026-09-10 (Scribe spike #3843) and the
same swap is verified on four other repos.

Artifact names, paths, if-no-files-found: error and the no
continue-on-error stance are unchanged. ci-requirements.md now says
stock v7 and keeps what is still true: @v3 uploads are invisible.

Scribe snippet #2271, milestone 395.

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

ci-requirements.md

@@ -45,22 +45,20 @@ 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`.**
+- **Artifacts — stock `actions/upload-artifact@v7`, never `@v3`.**
   ```yaml
-  uses: https://git.fabledsword.com/bvandeusen/upload-artifact@cb8afe72b42edc798abfb8fcb556cf660d894245
+  uses: actions/upload-artifact@v7
   ```
-  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.
+  Stock works on this forge since the runner moved to gitea/runner 3.x, which
+  edits the action's client-side `isGhes()` refusal out of its bundle. Proven on
+  2026-09-10 for upload-artifact v4–v7 and download-artifact v4–v8 (Scribe spike
+  #3843). Until then this repo pinned a SHA mirror of the Forgejo project's
+  fork, because upstream threw on the hostname before it opened a connection.
 
-  `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.
+  `@v3` is still broken: it reports success, and Gitea 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.
 
   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