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

.forgejo/workflows/android.yml

@@ -264,13 +264,12 @@ jobs:
           bash desktop/packaging/publish-release.sh
 
       - name: Upload the APK
-        # Mirrored action, never actions/upload-artifact. @v4+ throws
-        # GHESNotSupportedError client-side on this hostname, and @v3 is worse —
-        # it reports success while Gitea serves artifacts back only through the
-        # v4 API, so the upload is stored and invisible. Pinned by SHA because
-        # the mirror auto-syncs; full URL because DEFAULT_ACTIONS_URL sends bare
-        # owner/repo to github.com. See Scribe issues 2255 / 2270.
-        uses: https://git.fabledsword.com/bvandeusen/upload-artifact@cb8afe72b42edc798abfb8fcb556cf660d894245
+        # Stock action: it works on this forge since the runner moved to
+        # gitea/runner 3.x, which edits upload-artifact's client-side GHES refusal
+        # out of the action bundle (Scribe snippet #2271). Never @v3 — it reports
+        # success while Gitea serves artifacts back only through the v4 API, so the
+        # upload is stored and invisible (Scribe 2270).
+        uses: actions/upload-artifact@v7
         with:
           # The APK's variant, NOT the Cargo profile — those are the same word
           # for different things and the profile is pinned to debug (#2810).

.forgejo/workflows/desktop.yml

@@ -230,16 +230,15 @@ jobs:
         run: bash desktop/packaging/arch/package-prebuilt.sh
 
       # Make the built .deb + .AppImage downloadable from the run (for hand-testing).
-      # Mirrored action, never actions/upload-artifact: @v4+ throws
-      # GHESNotSupportedError on the hostname before it connects, and @v3 uploads
+      # Stock action: it works on this forge since the runner moved to
+      # gitea/runner 3.x, which edits upload-artifact's client-side GHES refusal
+      # out of the action bundle (Scribe snippet #2271). Never @v3 — it uploads
       # something Gitea stores but will never serve back (it returns artifacts only
       # through the v4 API, which filters on content_encoding='application/zip').
-      # Pinned by SHA — the mirror auto-syncs, so a moved upstream tag would
-      # silently change what runs. See Scribe issues 2255 / 2270.
       # No continue-on-error: a swallowed upload failure is exactly how 110
       # unreachable artifacts accumulated here unnoticed. Fail loudly instead.
       - name: Upload bundles
-        uses: https://git.fabledsword.com/bvandeusen/upload-artifact@cb8afe72b42edc798abfb8fcb556cf660d894245
+        uses: actions/upload-artifact@v7
         with:
           name: thoughtsync-linux
           path: |
@@ -376,11 +375,9 @@ jobs:
             --config "$updater"
         working-directory: desktop/src-tauri
 
-      # Mirrored action, never actions/upload-artifact — see the Linux job's
-      # Upload bundles step for the full reasoning. Pinned by SHA because the
-      # mirror auto-syncs.
+      # Stock action — see the Linux job's Upload bundles step for why.
       - name: Upload installer
-        uses: https://git.fabledsword.com/bvandeusen/upload-artifact@cb8afe72b42edc798abfb8fcb556cf660d894245
+        uses: actions/upload-artifact@v7
         with:
           name: thoughtsync-windows
           path: target/x86_64-pc-windows-msvc/release/bundle/nsis/*.exe

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