[GRADLE-WRAPPER] bug fix - pass maven java_home to gradle correctly

[Picazsoo]

My previous attempt to pass identical java_home used for maven to the underlying gradle was incorrect. I only noticed on my other machine where the default java_home points to java 25 which is not compatible with the kotlin version used by the gradle maven wrapper.

So this is another attempt to make it work. I tested locally that the correct java_home is propagated now.

Impact of the current incorrect implementation - there is no practical impact. It simply does not work (the same way it did not work before my original attempt to link the java_home). And it definitely has no practical impact on the released version as this practically only comes into play when building locally

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• Run the following to build the project and update samples:

  ./mvnw clean package || exit
  ./bin/generate-samples.sh ./bin/configs/*.yaml || exit
  ./bin/utils/export_docs_generators.sh || exit
  

  (For Windows users, please run the script in WSL)
  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
  IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
• File the PR against the correct branch: master (upcoming 7.x.0 minor release - breaking changes with fallbacks), 8.0.x (breaking changes without fallbacks)
• If your PR solves a reported issue, reference it using GitHub's linking syntax (e.g., having "fixes #123" present in the PR description)
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request. @wing328 - tagging you, since there is no dedicated committee for gradle. If there is no need to tag you, let me know and I will stop.

---

Summary by cubic

Ensure Gradle uses the same JDK as Maven by passing Maven’s ${java.home} via the plugin’s javaHome setting instead of -Dorg.gradle.java.home. Prevents Gradle from picking a different system JDK (e.g., JDK 25 when Maven runs on JDK 21).

^{Written for commit a2f6da0. Summary will update on new commits. Review in cubic}

[cubic-dev-ai]

No issues found across 1 file