ci: deploy the docs with GITHUB_TOKEN instead of an expired PAT

[kurkle]

Problem

Every push to master has failed at Release to GitHub Pages in the documentation workflow. All 21 runs still within the log retention window are red, and https://www.chartjs.org/chartjs-plugin-zoom/master/ has not been updated since the last successful deploy on 2025-02-15.

The build itself is fine; only the push is rejected (latest run):

[command]/usr/bin/git push origin gh-pages
remote: Invalid username or token. Password authentication is not supported for Git operations.
fatal: Authentication failed for 'https://github.com/chartjs/chartjs-plugin-zoom.git/'
##[error]Action failed with "The process '/usr/bin/git' failed with exit code 128"

secrets.GH_AUTH_TOKEN exists and is non-empty (the action logs [INFO] GithubToken: true), but GitHub rejects it. The repository secret was created on 2021-04-25 and has never been updated — a classic PAT that has since expired or been revoked. The gh-pages clone earlier in the same step still succeeds because the repository is public and that read needs no credentials.

Fix

Use the runner's own GITHUB_TOKEN for the four peaceiris/actions-gh-pages steps. It is scoped to this repository, is minted per run, and cannot expire on us again. The failing run's token already had Contents: write, and gh-pages is the configured Pages source (build_type: legacy), so peaceiris' "select the branch before the first deployment" caveat does not apply here.

The deploying jobs now declare permissions: contents: write explicitly, so the deploy no longer depends on the repository's default workflow permission staying at write.

publish-npm.yml used the same dead secret in its three Pages steps (version, latest, next), which would have failed the same way on the next release, so those are included.

Verification

• Root cause read from the failed job log, not inferred from config.
• Secret age from GET /repos/chartjs/chartjs-plugin-zoom/actions/secrets (created_at == updated_at == 2021-04-25).
• Both files still parse as valid workflow YAML.
• The deploy path itself cannot be exercised from a PR — gh-release only runs on push to master. It will run on merge; if anything is still wrong there it will be visible immediately in the documentation run for the merge commit.

GH_AUTH_TOKEN and GH_AUTH_EMAIL are now unused in this repository and could be deleted, but this PR leaves them alone.

🤖 Generated with Claude Code

[kurkle]

@etimberg I do not recall why we have the org wide PAT in use. It seems to be expired.. But do we need that?

[kurkle]

@etimberg this would also require removing the push limitation. So in addition to actions, maintainers would gain push access to pages. In my opinion that would be ok, when force pushed and deletions are disallowed. This is the reason we have the PAT. Rotating it would probably be fastest for all repositories, but I think it would have to be done yearly. Not ideal.
Thoughts?