Fall back to the runner token when the org secret is absent

pluginBase failed with "RELEASE_TOKEN is not set" while chatSummaries
published fine, from the same organisation secret. An organisation secret
is only exposed to a repository that has Actions enabled, so it can be
empty in one repo and present in another.

Try RELEASE_TOKEN first, then the runner-provided GITEA_TOKEN, which can
publish releases in its own repository, and report which one was used.
When none is set, name every variable that was tried and point at the
repository Actions setting rather than failing with a bare message.

The publish step also reports whether the organisation secret arrived,
printing only its length, so the fallback is visible in the job log.

README.md

@@ -125,8 +125,13 @@ credentials.
 
 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.
+`env:` entry of the same name, so the org secret would be silently ignored.
+
+If the org secret does not reach a repository the publish still works: `release.py` tries
+`RELEASE_TOKEN` first and then falls back to the runner's `GITEA_TOKEN`, which can publish
+releases in its own repository, and prints which one it used. An organisation secret is only
+exposed to a repository that has Actions enabled, so check **Repo → Settings → Actions** if a
+repo unexpectedly falls back.
 
 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