ci: move workflow actions off the deprecated Node 20 runtime

[foureight84]

The v2.5.0+35 release run warned that four actions target Node 20 and are being force-run on Node 24, and that setup-java v4 is EOL. Builds pass today; this closes it out before the forced-migration window does.

Action	From	To
actions/checkout	v4	v7
actions/setup-java	v4	v5
gradle/actions/setup-gradle	v4	v6 + cache-provider: basic
actions/upload-artifact	v4	v7
softprops/action-gh-release	v2	v3

Every one of these majors is a Node 20 → 24 runtime bump. I read the release notes for each; none changes an input this repo passes. Specifically:

• checkout v7 also blocks fork checkouts for pull_request_target and workflow_run — neither workflow uses those events (CI is on pull_request).
• upload-artifact v7 adds an optional archive input and leaves name / path / if-no-files-found / retention-days untouched.
• All require runner ≥ 2.327.1; GitHub-hosted ubuntu-latest is well past that.

setup-gradle: v6 with cache-provider: basic

v6 moved the default caching implementation into gradle-actions-caching, a proprietary component governed by Gradle's commercial Terms of Use. An earlier revision of this PR stopped at v5 to avoid that. Two things make v6 the better call:

1. v5 is a dead line. Last release v5.0.2 (2026-02-23); v6.0.0 landed a month later and there has been nothing on v5 since. v6.0.0's notes cite dependency updates for security vulnerabilities — so pinning v5 would fix the Node 20 deprecation by parking on a branch that gets no security updates.
2. v6 has an open-source caching mode, so the licensing concern implied a choice that doesn't actually exist. cache-provider selects between enhanced (default, the commercial component) and basic (the open-source GitHub Actions cache implementation).

cache-provider: basic therefore gets Node 24, an actively maintained line, security updates and caching, without accepting those terms:

	v5	v6 default	v6 + basic
Node 24	✅	✅	✅
Security updates	❌ dead	✅	✅
Caching	✅ MIT	✅ commercial	✅ open source
Commercial terms	none	accepted	none

Both workflows set the input explicitly and comment why, because the failure mode is silent: deleting the line doesn't break the build, it just opts into the commercial component on the next run.

v6 also drops the rudimentary configuration-cache support pending a reimplementation. These workflows run --no-daemon and never enabled the configuration cache, so that costs nothing here.

Note cache-provider exists as of v6.3.0, so this relies on the floating @v6 tag staying at 6.3.0+ — consistent with how this repo pins every other action. Pin @v6.3.0 exactly if you'd rather not depend on that.

Verification

Workflow YAML parses cleanly with the expected structure (ci: 1 job / 6 steps; release: 1 job / 8 steps). The real check is CI on this PR.

Caveat: this PR exercises ci.yml only. release.yml runs on tag pushes, so its changes stay unverified until the next release tag — worth knowing if the next release is time-sensitive. The changes are identical in kind to the ones CI does cover.