📝 Document the publish-step token gates

Record the two optional secrets and why the job lifts them into env: the
secrets context is unavailable in a step if, so env is the only place the gate
can read them.

CONTRIBUTING.md

@@ -46,7 +46,7 @@ Separately, some top-level scripts are **bare** (no prefix): the entry points th
 The tools are organized into a feedback ladder. Each tier catches different things at different costs; the rule of thumb is "earlier tiers fire more often, faster tiers catch less, slower tiers are more thorough":
 
 | Tier                             | When                    | What it runs                                                                                                                                   | Time  |
-| -------------------------------- | ----------------------- | -------------------------------------------------------------------------------------------------------- | ----- |
+| -------------------------------- | ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | ----- |
 | `npm run watch`                  | manual                  | `watch:test` — re-runs tests on file save                                                                                                      | ~0.1s |
 | Pre-commit (auto)                | on stage                | tsc + oxlint + oxfmt + cspell (staged files only)                                                                                              | ~1.3s |
 | Pre-push (auto)                  | on push                 | `npm test` (full tsc + unit tests)                                                                                                             | ~3.5s |
@@ -56,7 +56,7 @@ The tools are organized into a feedback ladder. Each tier catches different thin
 | `npm run maintain`               | manual / CI (advisory)  | `maintain:knip` + `maintain:outdated` (whole-project + network scans)                                                                          | ~10s  |
 | CI build (auto)                  | on push to `main` / tag | `build` job (build + correctness + packaging) — see [.gitea/workflows/ci.yml](./.gitea/workflows/ci.yml)                                       | ~30s+ |
 | CI maintain (auto, non-blocking) | on push to `main`       | `npm run maintain` — reports, never fails the build                                                                                            | ~10s  |
-| CI publish (auto)                | on tag                  | Gitea release page (body from CHANGELOG) + `publish:publint` + `publish:attw`, then `npm publish`        | ~15s  |
+| CI publish (auto)                | on tag                  | packaging checks + `publish:publint` / `publish:attw`, then a release page (if `GITEA_TOKEN` is set) and `npm publish` (if `NPM_TOKEN` is set) | ~15s  |
 
 ### Why these splits?
 
@@ -115,3 +115,5 @@ Publishing is CI-only by policy. Local `npm publish` is not supported. The maint
 2. The maintainer runs `npm run create:release`. VS Code opens `CHANGELOG.md` to finalize the `[Unreleased]` notes; because pubv refuses a dirty tree, any edit is committed first (then folded into the release commit), and pubv's interactive prompt suggests a version from those notes — the maintainer confirms or edits it.
 3. `scripts/release.sh` creates a single release commit (graduated changelog + package.json bump, amended into one commit), tags it, and pushes everything to Gitea.
 4. CI fires on both pushes: the `publish` job runs on the tag (`build` + publish-tier checks + release page + `npm publish`), while the branch run's `release-gate` job recognizes the release commit and skips `build`/`maintain` — the tag verifies the identical SHA, so no work is duplicated. The job graph lives in [.gitea/workflows/ci.yml](./.gitea/workflows/ci.yml) — keep that file, not this list, as the source of truth. The publish-tier checks must pass before the artifact is published. The `publish` job also creates the Gitea release page from the matching Keep-a-Changelog section (`scripts/release-notes.sh`); it runs _before_ `npm publish` so a broken page fails CI without consuming a version, and `npm publish` stays the last step.
+
+Each publish step is gated on its own secret, so a tag run without the maintainer's secrets (a fork, a manual dispatch) still runs the packaging checks and goes green instead of failing an assert: the release page needs `GITEA_TOKEN` and `npm publish` needs `NPM_TOKEN`. `secrets` is not an allowed context in a step `if`, so the job lifts both into job-level `env` and tests `env.<NAME> != ''`. Create both under Settings → Actions → Secrets: `NPM_TOKEN` with npm publish rights, `GITEA_TOKEN` a Gitea token with repository write access. With both set, the combined run behaves as before.