Fix the concurrency group, bump tooling, unpin CodeQL and gradle actions

[bernardladenthin]

Summary

• The concurrency: block did not do what its comment claimed. It said a push to main or a v* tag "always runs to completion even if another push lands behind them", on the strength of cancel-in-progress being scoped to pull_request. That is not what GitHub does: it cancels a pending run whenever a newer run joins the same group behind an in-progress one, and that rule is independent of cancel-in-progress. With a plain ${{ github.workflow }}-${{ github.ref }} group, a queued release run on main could therefore be dropped silently by a later push to main — both sit in Publish-refs/heads/main. Appending the unique github.run_id for every non-PR run puts each release run in a group of its own; PR runs keep sharing a group per ref and still supersede each other, which is the point of the block.
• Two accidental hard pins removed. github/codeql-action was pinned at @v4.37.8 across codeql.yml and scorecard.yml (init, analyze, upload-sarif) and now floats on @v4 like the sibling repos — 4.37.9 is already out. gradle/actions/setup-gradle drops @v6.3.0 to @v6 for the same reason.
• Build tooling bumped: spotless-maven-plugin 3.10.0 → 3.10.1, palantir-java-format 2.96.0 → 2.97.0, pitest-maven 1.25.9 → 1.30.0.

nullaway is untouched here on purpose — this repo is already on 0.14.0 via Dependabot PR #149, and that is precisely the version the other three siblings were just aligned to. That single-repo bump is also what silently broke the "identical across all 4" claim in crossrepostatus.md, which is corrected in the workspace PR of this sweep.

Expect one overlapping run, exactly once

GitHub reads concurrency from the workflow file at each run's own ref, so a run started before this change sits in the old group and one started after it sits in the new one. They are different groups, so the new push does not supersede the in-flight old run — once, on the commit that lands this. It self-heals from the next push on. This is documented in the block's own comment; it is not a sign the expression is wrong.

Deliberately not taken

versions:display-dependency-updates also offers, and each is refused on purpose:

• jqwik 1.9.3 → 1.10.1 — forbidden by workspace/policies/jqwik-prompt-injection.md: 1.10.0 added a deliberate prompt-injection string to test stdout, and upstream states the library "is not meant to be used by any 'AI' coding agents at all."
• maven-compiler/jar/source 4.0.0-beta-*, surefire 3.6.0-M1 — pre-releases the plugin offers because it does not filter by qualifier.

Test plan

• Affected unit / integration tests pass locally — spotless:check OK and clean compile OK, verified with real exit codes (a first attempt put rc=$? after a pipe, measuring tail, and reported success unconditionally; redone). Those are the two checks that matter: palantir 2.97.0 would fail spotless:check if the formatter's output had changed, and the compile runs under -Werror.
• CI is green on this branch — pending on this PR. pitest 1.30.0 is five minor versions against a whole-package mutationThreshold of 100; a local mutationCoverage run was still in flight when this PR was opened, so CI is the authority there. If it goes red, the pitest bump alone is what to revert — nothing else here depends on it.
• Docs / CHANGELOG updated where applicable — the rationale lives in the workflow comment and in workspace/crossrepostatus.md.

Related issues / PRs

Refs #149 (the nullaway 0.14.0 bump this sweep aligns the other repos to). Part of a cross-repo sweep also landing in java-llama.cpp, BitcoinAddressFinder, srcmorph, BroomCabinet and workspace.

Checklist

• I have read CONTRIBUTING.md and CODE_OF_CONDUCT.md
• My commits follow Conventional Commits
• No security-sensitive changes

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate failed

Failed conditions
C Security Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE