ci: declare contents:read on Java CI workflow

[arpitjain099]

Adds a workflow-level permissions: contents: read block to .github/workflows/ci-pull-request.yaml. The Java CI job only does checkout, JDK setup, and mvn verify; nothing here needs anything beyond read access to the repository.

The motivation is supply-chain blast-radius capping. CVE-2025-30066 (the March 2025 tj-actions/changed-files compromise) showed that a tampered third-party action can exfiltrate GITHUB_TOKEN via the workflow logs, and the leaked token retains whatever scope it was issued with. Pinning the workflow token to contents: read bounds that runtime authority. The repo default may already be read-only, but an in-file declaration adds drift protection (a future change to the org or repo default can't silently widen this workflow) and lights up OpenSSF Scorecard's Token-Permissions check, which only counts explicit per-workflow declarations.

YAML validated locally with yaml.safe_load.

[nicklasl]

Thanks for the contribution and for flagging the permissions hardening — we appreciate the security awareness!

We'll look into this and handle it internally. For future contributions to this repo, please refer to our contribution guidelines.