ci(docs): rebuild the site when the root changelog changes

[santosr2]

What and why

Make the documentation site rebuild when the root CHANGELOG.md changes. Two compounding bugs kept the published changelog stale.

Why: The live site tops out at [0.2.0] - 2026-07-22 while the repo is on [0.3.0] - 2026-08-31. It is also missing the release-notes repair from #285.

The first bug is the path filter. docs/site/docs/changelog.md is a symlink to the root CHANGELOG.md, and MkDocs resolves it correctly at build time, so the wiring looks fine. But a symlink's git blob is just its constant target path (../../../CHANGELOG.md), which never changes. Regenerating the changelog therefore touches no path under docs/site/**, docs.yml never fires, and the site only refreshed by accident whenever an unrelated commit happened to touch docs/site/. That is exactly what happened last: the most recent deploy came from the v0.3.0 release-prep commit, and the two commits that actually updated the changelog afterwards changed zero files under docs/site/.

Adding CHANGELOG.md to the filter is necessary but not sufficient. The update-changelog job in release.yml pushes its commit with GITHUB_TOKEN, and GitHub deliberately suppresses workflow runs triggered by that token, so the release-time changelog commit would still never rebuild the site. workflow_dispatch is one of only two events GITHUB_TOKEN may still trigger, so that job now dispatches the docs workflow explicitly. No PAT required.

How to test

Merging this PR is itself the test. The commit touches .github/workflows/docs.yml, which is in the push path filter, so it self-triggers a build and deploy. After the run completes, https://santosr2.github.io/TerraTidy/changelog/ should show a 0.3.0 section instead of topping out at 0.2.0.

Locally:

# The symlink resolves and the built page carries the current release
mise run docs:build
grep -o 'id=030-2026-08-31' docs/site/site/changelog/index.html

# Workflow linting
pre-commit run actionlint --files .github/workflows/docs.yml .github/workflows/release.yml
pre-commit run zizmor --files .github/workflows/docs.yml .github/workflows/release.yml

The release-time dispatch path can only be exercised by an actual tag push, so it is verified by inspection here.

Notes for reviewers

The deploy gate widened, and it is worth a look. It moved from github.event_name == 'push' && github.ref == 'refs/heads/main' to github.event_name != 'pull_request' && github.ref == 'refs/heads/main', because a workflow_dispatch run would otherwise build without deploying. The practical effect is that anyone who can dispatch the workflow can now trigger a Pages deploy. That was already true of anyone who could push to main, and the refs/heads/main condition still blocks publishing an arbitrary branch, so I read this as no meaningful change in exposure. Happy to tighten it if you disagree.

update-changelog gains actions: write, which gh workflow run requires.

Unrelated and untouched: vscode/CHANGELOG.md and vscode/LICENSE are also symlinks, and vscode.yml has the same path-filter blind spot. It is harmless there. That workflow is CI-only, and the marketplace publish job in release.yml already regenerates the changelog at package time precisely because a tag's tree freezes it at the pre-release state. Confirmed: git show v0.3.0:CHANGELOG.md tops out at [0.2.0].

No tests accompany this change; it is a CI trigger fix with no unit-testable surface. mise run check was not run in full since no Go code changed, but the complete pre-commit suite passes, including actionlint, zizmor, and yamllint.

Checklist

• I have read the CONTRIBUTING guidelines
• My code follows the project's code style
• I have added tests that prove my fix/feature works (n/a: CI trigger change, verified by build and workflow linters)
• All checks pass (full pre-commit suite; mise run check n/a, no Go changes)
• I have updated documentation as needed (n/a: no user-facing docs change; this restores publishing of existing docs)
• My commits follow Conventional Commits

---

🤖 Generated with Claude Code