ci: grant contents:read to PR labeler so domain labels apply

[bryanbeverly]

Summary

Add contents: read to the PR labeler caller workflow's permissions block.

When a workflow declares a permissions: block, every scope not listed defaults to none. This caller declared only pull-requests: write, so contents was none. The labeler's domain-labeling step reads CODEOWNERS via the GitHub Contents API using GITHUB_TOKEN; with contents: none that read is denied and the script logs "No CODEOWNERS found; skipping domain labeling." As a result the domain/* labels added org-wide in trufflesecurity/.github#13 were never applied. Granting contents: read restores CODEOWNERS access; no other scope is required.

Review guidance

• Urgent (needs same-day review): no
• High complexity (non-obvious logic, careful review): no
• Key files to focus on: .github/workflows/pr-labeler.yml

Testing

A labeler dry-run backfill on thog logged "No CODEOWNERS found; skipping domain labeling" under the current permissions, despite a valid CODEOWNERS file. contents: read is the documented scope for the Contents API read the labeler performs. After merge, gh workflow run pr-labeler.yml -f pr_number=all -f dry_run=true will show planned domain/* labels.

Deployment notes

Takes effect on the next labeler run (event-driven, or a workflow_dispatch backfill). No application/runtime impact.

---

Note

Low Risk
Single workflow permission scope change with no application or runtime impact; least privilege is preserved aside from the required Contents API read.

Overview
The PR labeler workflow now grants contents: read alongside pull-requests: write.

Because an explicit permissions block leaves unlisted scopes at none, the labeler could not read CODEOWNERS via the Contents API and skipped domain labeling. This restores that read so org-wide domain/* labels can be applied again.

^{Reviewed by Cursor Bugbot for commit e0f6721. Bugbot is set up for automated code reviews on this repo. Configure here.}