Read the release token from RELEASE_TOKEN

The publish step set GITEA_TOKEN from the org-level API_TOKEN secret, but
the Actions runner injects its own GITEA_TOKEN into every step and that
value overrides a step-level env: entry of the same name. The org secret
was silently ignored and the job failed.

Pass the secret as RELEASE_TOKEN instead, which the runner does not
reserve, and read that name in release.py. --token-env makes the source
configurable, so the runner-provided GITEA_TOKEN can still be used
deliberately by passing --token-env GITEA_TOKEN.

README.md

@@ -123,10 +123,15 @@ token with the `write:repository` scope (which covers releases). Set it once und
 repo-level secret of the same name takes precedence if one repo ever needs different
 credentials.
 
-If you would rather not manage a token, Gitea also injects a per-job `secrets.GITEA_TOKEN`
-that can create releases in its own repo — swap the `env:` line in the workflow and drop the
-org secret. It is scoped to the single job and expires with it, so it is the safer default;
-`API_TOKEN` is what you want when publishing needs to reach beyond this repo.
+The workflow passes it to `release.py` as `RELEASE_TOKEN`, **not** `GITEA_TOKEN`. The Actions
+runner injects its own `GITEA_TOKEN` into every step, and that value overrides a step-level
+`env:` entry of the same name, so the org secret would be silently ignored and the publish
+step would fail on permissions. Use `--token-env` if you need a different variable name.
+
+If you would rather not manage a token at all, that injected `GITEA_TOKEN` can create
+releases in its own repo: pass `--token-env GITEA_TOKEN` and drop the org secret. It is
+scoped to the single job and expires with it, so it is the safer default; `API_TOKEN` is what
+you want when publishing needs to reach beyond this repo.
 
 ## Writing your own plugin