ci: declare contents: read permissions on cifuzz workflow

[arpitjain099]

Adds a top-level permissions: block declaring contents: read on .github/workflows/cifuzz.yaml.

The CIFuzz fuzz-testing workflow runs on pull requests and pushes to perform fuzz coverage; it does not push commits, create releases, comment on PRs, or call any GitHub write API. contents: read is therefore the minimum sufficient token scope.

I previously opened a related PR (#1188) for the gradle-wrapper-validation workflow in this repo. This is the same shape applied to the fuzz workflow, kept as a separate PR so each can be reviewed in isolation.

A short list of reasons this is cheap-but-worth-doing:

• The OpenSSF Scorecard Token-Permissions check flags any workflow that does not declare explicit perms.
• After the tj-actions/changed-files supply-chain incident (CVE-2025-30066, March 2025), explicit minimum permissions are one of the cheaper defenses against compromised third-party actions.
• GitHub's own hardening guide recommends this pattern.

Validated locally with python3 -c "import yaml; yaml.safe_load(open('.github/workflows/cifuzz.yaml'))". No other edits.

[loosebazooka]

can you combine with #1188 and rebase?

[loosebazooka]

these are repository defaults, so it's essentially a no-op, but there doesn't seem to be an issue in explicitly adding these.

[arpitjain099]

these are repository defaults, so it's essentially a no-op, but there doesn't seem to be an issue in explicitly adding these.

@loosebazooka ok let me update this

[arpitjain099]

That's right @loosebazooka - it's intentionally a no-op right now. The benefit is pinning the scope explicitly so it stays correct regardless of future changes to the repo-wide default (defense-in-depth). Thanks for taking a look.

[arpitjain099]

Rebased and added the newline. #1188 has since merged, so its gradle-wrapper-validation change is already on main and this PR is now just the cifuzz workflow change on top. Ready for another look.