ci: declare least-privilege workflow-level contents: read

[arpitjain099]

Small CI hardening: declares an explicit workflow-level permissions: contents: read on 1 workflow(s) that currently inherit the default broad read-write GITHUB_TOKEN.

I inspected each file before including it; none publish, push, comment on issues/PRs, or otherwise write via the GitHub API, so the read-only default does not change behavior. Workflows that need to write (stale, release, gh-pages-deploy, publish actions, etc.) are intentionally left out of this PR.

This is the post-CVE-2025-30066 hardening pattern for default token scope.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[bartlomieju]

Thanks for the contribution, and for being careful to inspect each workflow first.

We're going to pass on this one, though. The change targets release.yml, which only runs on workflow_dispatch (manual, maintainer-only), so it has no untrusted-input attack surface — and its actual privilege comes from DENOBOT_PAT (used for both checkout and the release step), not the default GITHUB_TOKEN. Restricting the default token to contents: read therefore doesn't constrain anything this workflow meaningfully uses, and the CVE-2025-30066 / tj-actions threat model (a malicious action abusing the token on PR-triggered runs) doesn't apply to a manually-dispatched release job.

The workflow where this hardening would actually add defense-in-depth is ci.yml, since that's triggered by pull_request (including forks) and currently inherits the broad default token. If you'd like to pursue that, please open an issue first so we can discuss the right shape (likely a job-level contents: read with the publish step getting only what it needs).

Closing for now — appreciate the effort!