CI: grant pull-requests:read to pr-verifier caller

[rh-dnagornuks]

Summary

The permissions: {} block added in e5a5605 locked all token permissions
to none at the workflow level. GitHub enforces the caller's permissions
as a hard ceiling for any reusable workflow it invokes, so the nested
pr-title-check job in kagenti/.github/workflows/pr-verifier-required.yml
was blocked from requesting pull-requests: read — causing the workflow to fail.
The workflow after that commit has failed to run on every PR made since:
https://github.com/kagenti/kagenti-operator/actions/workflows/pr-verifier.yml

Changes

• Replace permissions: {} with permissions: pull-requests: read in
  .github/workflows/pr-verifier.yml — the minimum scope required by the
  reusable workflow

Test Plan

• The workflow runs successfully on a valid PR rh-dnagornuks/kagenti-operator/pull/1

Made with Cursor

[cwiklik]

Correct, minimal CI permissions fix: replaces permissions: {} (which starved the reusable pr-verifier-required.yml of the token scope it needs to read the PR) with the least-privilege pull-requests: read. Safe by construction — the pull_request trigger yields a read-only token even for fork PRs, and the value granted is read-only. The required verify-pr-title check now passes.

Security: least-privilege read-only grant; pull_request (not pull_request_target); reusable workflow pinned to a SHA — all good.

Commits: signed-off. Nit: subject Ci: should be lowercase ci: (conventional commits); the repo's own title check accepts it, so non-blocking.

All 17 CI checks passing.

[cwiklik]

nit (optional, least-privilege hygiene): consider scoping this to the verify-pr-title job (jobs.verify-pr-title.permissions.pull-requests: read) rather than top-level. Equivalent today with a single reusable-workflow job, but job-level scoping keeps the grant from silently extending to any future job added to this workflow. The pull-requests: read value itself is exactly right.