Use the built-in GITEA_TOKEN instead of a hand-made RELEASE_TOKEN secret

Gitea injects a token into every Actions job as secrets.GITEA_TOKEN, so the
manually created PAT was never necessary. Declare permissions: contents:
write on the job, which Gitea maps to Code: write (deleting the latest-main
tag) and Releases: write (creating the release, uploading the asset) - the
full set the publish step needs.

Removes a secret that had to be created by hand, could expire, and was a
single point of failure the workflow had no fallback for.

.gitea/workflows/build-main.yml

@@ -10,6 +10,11 @@ on:
 jobs:
   package:
     runs-on: gitea-runner-server03
+    # contents: write maps to Code: write (deleting the latest-main tag) plus
+    # Releases: write (creating releases and uploading the asset) - everything
+    # the publish step below needs, so it runs on the built-in GITEA_TOKEN.
+    permissions:
+      contents: write
     steps:
       - uses: actions/checkout@v7
 
@@ -30,7 +35,7 @@ jobs:
         env:
           GITEA_API: ${{ gitea.server_url }}/api/v1
           REPO: ${{ gitea.repository }}
-          TOKEN: ${{ secrets.RELEASE_TOKEN }}
+          TOKEN: ${{ secrets.GITEA_TOKEN }}
           SHA: ${{ gitea.sha }}
           REF: ${{ gitea.ref }}
         run: |

CLAUDE.md

@@ -64,7 +64,9 @@ The `latest-main` half exists so a build can be grabbed and copied onto the serv
 
 Note that `make appstore` is pure `mkdir`/`tar`/`rm` — no `composer`, no `php`. The workflow therefore needs Node only; a `setup-php` step here would be dead weight (the deleted release workflow had one).
 
-Both halves require a **repo secret named `RELEASE_TOKEN`**, a Gitea Personal Access Token with repo write access (create it under the repo owner's Gitea user settings → Applications, then add it under the repo's Settings → Actions → Secrets). Without that secret, the `curl` calls to the Gitea release API in the job will fail with 401s — the workflow doesn't fall back to anything else.
+**No manually created token is needed.** The publish step authenticates with `secrets.GITEA_TOKEN`, the token Gitea injects into every Actions job automatically (Gitea 1.27.1 here). The job declares `permissions: contents: write`, which Gitea maps to *Code: write* (needed to delete the `latest-main` tag) plus *Releases: write* (creating the release and uploading the asset).
+
+This replaced an earlier hand-made `RELEASE_TOKEN` repo secret. If the publish step ever starts returning 403s, check the repo/org **default token permission mode**: `permissions:` requests are clamped by `MaxTokenPermissions`, so a repository switched from *Permissive* (the backwards-compatible default) to *Restricted* silently downgrades releases to read-only and no `permissions:` block can raise it back. That's a repo setting, not a workflow bug — don't "fix" it by reintroducing a PAT before checking.
 
 ## Data flow / architecture map