[Martin Torp (mtorp)]

Part of REA-1043. Older Gradle and sbt versions refuse to start on newer JDKs. So a machine whose default JDK is newer than the project's pinned build tool fails to generate Socket facts, even when a suitable JDK is installed next to it. Managed reachability scans want to move their default JDK to 25, and Gradle 8 projects are where that breaks. The depscan side is SocketDev/depscan#29251, which installs Temurin 8, 11, 17, 21 and 25 side by side.

When facts generation runs a Gradle wrapper or sbt build, the CLI now reads the version the project pins and checks it against the JDK in JAVA_HOME (or the java on PATH). If the build tool doesn't run on that JDK, the build runs on the newest installed JDK it does run on, and the CLI logs which one:

ℹ Running gradle 8.14.3 on Java 21 at /usr/lib/jvm/temurin-21, since it does not run on Java 25 at /usr/lib/jvm/temurin-25.

• Versions: the Gradle version comes from gradle/wrapper/gradle-wrapper.properties and the sbt version from project/build.properties. A Gradle on PATH, a custom bin and Maven keep the current JDK.
• Supported ranges: Gradle follows its compatibility matrix. Gradle 9 needs at least 17. sbt needs 1.3 for Java 17 and 1.9 for Java 21 and 25, which I measured (table below). A version newer than the table knows is allowed on any JDK.
• Discovery: JDKs are found by their release file in the children of /usr/lib/jvm, /usr/lib64/jvm, /usr/java and /opt/java, in SDKMAN, in ~/.gradle/jdks and ~/.jdks, in macOS JavaVirtualMachines bundles, and through the JAVA_HOME_<release>_<arch> variables GitHub and Azure runners set.
• What stays the same: a javaHome from socket.json is used as is. If no installed JDK fits, the build runs on the current one, as it did before.

Where each build tool started and resolved a Guava dependency (Temurin in Docker):

Build tool	8	11	17	21	25
Gradle 4.10.3, 5.6.4	✅	✅
Gradle 6.9.4		✅	❌
Gradle 7.6.4		✅	✅		❌
Gradle 8.5, 8.14.3			✅	✅	❌
Gradle 9.0.0	❌		✅		✅
sbt 0.13.18	✅	✅	✅
sbt 1.2.8		✅	❌
sbt 1.3.13, 1.5.8			✅	❌	❌
sbt 1.8.3				❌	❌
sbt 1.9.0, 1.9.9, 1.10.11					✅

Testing: unit tests for version parsing, ranges, discovery and selection use real temp-dir JDK layouts. A run.mts test checks that the spawned build gets the picked JAVA_HOME and that a configured one is kept. End to end, I ran the built CLI in an image with JAVA_HOME set to Temurin 25 and all five JDKs installed. socket manifest gradle on a Gradle 8.14.3 wrapper project ran on 21, and socket manifest scala on an sbt 1.5.8 project ran on 17. Both wrote facts containing the dependency. Without this change both builds fail to start on 25.

Follow-ups, not in this PR:

• A retry on a recognisable failure, for example a toolchain languageVersion that isn't installed.
• Per-project JDK hints such as .sdkmanrc, .tool-versions and actions/setup-java.
• A port to main.

Expected reviewer effort: High-level design decisions