ci: add permissions: contents: read to main

[arpitjain099]

This adds an explicit permissions: block to the CI workflow so the GitHub-issued token for runs of main.yml is granted only the scopes the job actually uses.

The change is permissions: contents: read at the top level. The workflow checks out the repo and runs its declared steps; there is no git push, no gh release create, no comment-on-PR action, no API write. contents: read is therefore the minimum sufficient scope.

Why bother for a workflow that looks innocuous: the worry is not what this workflow does today, it is what an action used inside it might be coerced into doing tomorrow if a third-party dependency in the action chain is compromised. The CVE-2025-30066 (tj-actions/changed-files, March 2025) incident is the canonical recent example. Without an explicit permissions: block, the run inherits the repository-default token scope, which is permissive on many older repos.

Aligns with GitHub's own token-hardening guidance and OpenSSF Scorecard (Token-Permissions). Standalone diff, no behavior change, YAML re-parses with yaml.safe_load.

[changeset-bot]

⚠️ No Changeset found

Latest commit: da5835a

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR