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.

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