Java backend: depend on the codeanalyzer-java wheel (bundled JVM) instead of a bundled jar plus _jdk.py #339

Problem

The Java backend carries its analyzer two ways that the other backends do not: the jar is checked in and force-included under cldk/analysis/java/codeanalyzer/jar/ (release.yml injects another copy at build time, #336), and cldk/analysis/java/codeanalyzer/_jdk.py downloads a pinned Temurin JDK with jmods/ into <cache_dir>/java/jdk/ on first use, exporting JAVA_HOME because the analyzer's WALA scope read $JAVA_HOME/jmods. That is ~35 MB in every cldk wheel and a ~200 MB download per project cache, plus JDK-resolution code the SDK has to maintain.

codeanalyzer-java 3.0.2 removes the reason for all of it (codeanalyzer-java#222): the analyzer reads its primordial scope from the running JVM through jrt:/, so no JAVA_HOME and no jmods/ are needed, and it ships on PyPI as codeanalyzer-java, a pure wheel with the jar under _bin/ and jdk4py (Temurin 21) as the runtime. The package exposes jar_path(), java_path() and command(*args), the same seam codeanalyzer-typescript.bin_path() gives the TypeScript backend.

Scope boundary

In scope: pyproject.toml depends on codeanalyzer-java==<pin> next to the other two backends, and the pin in [tool.backend-versions] becomes real; JCodeanalyzer._get_codeanalyzer_exec returns codeanalyzer_java.command(); delete _jdk.py, _locate_jar, the checked-in jar, the [tool.hatch.build] artifacts force-include, and the jar inject/verify steps in release.yml; tests that monkeypatch ensure_jdk follow.

Out of scope: the Java model migration to schema v2 (#310) — but it is a prerequisite, because the only current wheel is 3.0.2 (v2 output; the 2.3.7 on PyPI is a stale native-image build). Land this on top of leg 3, or in the same PR if the pin bump is small.

Goals

• pip install cldk on a machine with no Java runs CLDK.java(...) at AnalysisLevel.call_graph
• No JAVA_HOME is read or set by the SDK; no JDK is downloaded; no jar is checked in or injected
• The codeanalyzer-java pin is the single source of the analyzer version, and release.yml no longer fetches from releases/latest (closes the mechanism release.yml ignores the codeanalyzer-java pin and bundles releases/latest #336 patches)

Caveats and known risks

• codeanalyzer-java pins jdk4py>=21,<22: WALA 1.6.x's Shrike rejects class files above version 67, and jdk4py 25 ships version 69. The SDK inherits that pin transitively; nothing to do unless an SDK dependency ever wants jdk4py 25.
• jdk4py carries a GPLv2 license classifier (Temurin's GPLv2 + Classpath Exception, like every JDK). License scanners on downstream Apache-2.0 trees may flag it; document it, do not work around it.
• Windows: codeanalyzer_java.__main__ falls back to subprocess.call there; the SDK already spawns via subprocess, so no change, but it is untested on Windows.
• cache_dir no longer hosts a JDK. Single-file source mode (fix(java): source-code analysis crashes with Path(None) — JDK cache resolution assumes a project dir #256) loses the "cannot host a JDK" failure and should now just work; confirm rather than assume.

Definition of done

• Fresh venv with no Java on PATH and JAVA_HOME unset: CLDK.java(project_path=<daytrader8>, analysis_level=AnalysisLevel.call_graph).get_call_graph() returns the same edge set the previous JDK-download path returned (1876 edges on daytrader8 at analyzer 3.0.2; 1391 declared+rta, 375 rta, 110 declared)
• grep -r 'JAVA_HOME\|ensure_jdk\|jmods' cldk is empty; cldk/analysis/java/codeanalyzer/jar/ and _jdk.py are gone
• Built wheel contains no .jar; unzip -l dist/*.whl | grep -c '\.jar$' is 0
• Java test suite green with the ensure_jdk monkeypatch removed