ci: add explicit GITHUB_TOKEN permission scopes to workflows

[Makeph]

Closes #1350.

No workflow declared a permissions: block, so every job ran with the repository's default GITHUB_TOKEN scopes. Depending on repository and organisation settings, those defaults can include write access to contents, packages and pull requests — considerably more than any of these jobs needs.

I went through every workflow under .github/workflows/, not just the two named in the issue. Each one now denies everything at the top level (permissions: {}) and grants the minimum back per job.

What each job got, and why

Workflow	Job	Scopes	Reason
build_release_assets.yml	build_wheel_sdist, build_os_packages	contents: read	checkout
	linux_package_smoke_tests	none	only consumes artifacts from its own run
changelog-check.yml	check-changelog	none	the action takes no token input and works anonymously on public repos
ci.yml	lint, build, functest_api, test_github_secret_scan_action	contents: read	checkout; Codecov and GitGuardian use their own credentials
	build_os_packages	contents: read	passed through to the reusable workflow
	push_docker_images-unstable	contents: read, packages: write	GHCR publishing; Docker Hub uses separate credentials
install-scripts.yml	bats	contents: read	checkout, plus authenticated public release API reads
perfbench.yml	benchmark	contents: read	checkout with full history
tag.yml	release	contents: write, id-token: write, attestations: write	unchanged — creates the release, uploads assets, writes provenance
	push_to_pypi, push_to_cloudsmith, push_to_chocolatey	contents: read	checkout; each publishes with its own API key
	push_docker_images	contents: read, packages: write	GHCR publishing
update-downstream.yml	update-ggshield-version	none	checkout, push and PR creation all use PAT_GITHUB

Two things worth flagging

• tag.yml references ./.github/workflows/update_vscode_extension.yml, but that file isn't present in the repository. I left that job's permissions untouched (it inherits the empty default) since I can't see what it needs — happy to adjust if you can tell me.
• Workflow changes in a fork PR aren't executed by CI (pull_request runs use the base branch's workflow files), so this can't be validated by the checks on this PR. I verified statically that all seven files parse and that the resulting permission tree is what's described above. You may want to confirm on a branch in the main repo before merging.

If you'd rather have a single workflow-level contents: read instead of permissions: {} plus per-job grants, say the word and I'll rework it.

---

Prepared with AI assistance; I reviewed every line and verified the YAML parses and resolves to the permission tree documented above.