ci: declare contents:read on slack-lite workflow

[arpitjain099]

Pins this scheduled workflow to permissions: contents: read at the workflow level. The job checks out the repo, runs the data-gathering scripts, and posts the result to an external endpoint (Slack, internal dashboard, etc) using a separately-stored bot token. GITHUB_TOKEN itself is only used by the initial checkout, which is a read operation.

The reason to declare this explicitly even on a cron-style workflow that already routes writes through a different token is CVE-2025-30066 (the March 2025 tj-actions/changed-files supply-chain compromise). A tampered third-party action exfiltrates GITHUB_TOKEN from workflow logs and the leaked token carries whatever scope was issued at the workflow level. Without a per-workflow declaration, that scope defaults to the org or repo default, which is often broader than what the workflow actually uses. Capping at contents: read bounds the runtime authority irrespective of that default, gives drift protection if it ever widens, and registers with OpenSSF Scorecard's Token-Permissions check.

YAML validated locally with yaml.safe_load.

[github-actions]

🤖 GitHub comments

Just comment with:

• run docs-build : Re-trigger the docs validation. (use unformatted text in the comment!)

[trentm]

Thanks.