Update valitydev/java-workflow action to v4

[renovate]

This PR contains the following updates:

Package	Type	Update	Change
valitydev/java-workflow	action	major	v3 → v4

---

Release Notes

valitydev/java-workflow (valitydev/java-workflow)

v4

Compare Source

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

In general, the fix is to explicitly specify a minimal permissions block so that the GITHUB_TOKEN used by this workflow is restricted according to the principle of least privilege. This can be done at the workflow root (applies to all jobs) or per job. Since this workflow contains only a single job, adding permissions at the root is the simplest and most self‑documenting fix.

The best way to fix this specific file without changing existing functionality is to add a permissions block near the top of the workflow, alongside name: and on:. Because we don’t see any direct token usage in this file (the logic lives in the reusable workflow), a safe, minimal starting point is to grant read access to repository contents only, which matches GitHub’s recommended baseline: permissions: { contents: read }. If the reusable workflow requires additional scopes (e.g., to write to PRs), they can be added later, but starting with contents: read satisfies CodeQL’s requirement and enforces least privilege by default.

Concretely, in .github/workflows/build.yml, insert:

permissions:
  contents: read

between name: Maven Build Artifact and the on: block (lines 1–3). No imports or additional methods are needed, since this is purely a YAML configuration change.