Honor a system/global JDK instead of downloading Temurin per analysis cache

[rahlk]

PROBLEM

JCodeanalyzer's ensure_jdk downloads a Temurin JDK into each analysis cache dir — per project, potentially per service — so a machine analyzing ten projects fetches ten JDKs. This defeats pre-baking a JDK into a container image and costs a network fetch per analyzed project. Surfaced by COCOA's Docker packaging (codellm-devkit/cocoa#1).

SCOPE BOUNDARY

JDK discovery only. Not the analyzer distribution — sourcing codeanalyzer-java from PyPI was tried and reverted over GraalVM issues (#161, #162, closed won't-do), so the bundled jar stays and this must be solved on its own terms. Not JDK version policy, and not the pinned JDK_RELEASE itself.

GOALS

• Probe for a usable JDK before downloading: JAVA_HOME, then a CLDK_JDK env or global cache path.
• Verify the found JDK is version-compatible, not merely present.
• Fall back to the current Adoptium download when no compatible JDK is found.
• Log which JDK was selected and why, at DEBUG.
• Document the precedence order.

CAVEATS AND KNOWN RISKS

• Presence is not compatibility. JAVA_HOME on a dev machine is frequently stale or points at a different major. Accepting it unverified moves the failure from "slow download" to "analyzer crashes with an obscure JVM error" — strictly worse.
• Silent fallback hides misconfiguration: a user who sets JAVA_HOME expecting it to be used, and is quietly ignored, has no signal. Hence the log line is part of the contract, not polish.
• The per-project cache dir is also what makes analyses independent; a shared global JDK path is shared mutable state across concurrent runs.

DEFINITION OF DONE

• With a compatible JAVA_HOME set, analysis completes and no download occurs — asserted in a test, not observed by eye.
• With an incompatible JDK on JAVA_HOME, the run falls back to download and logs the reason.
• A container image with a pre-baked JDK analyzes a project with no network access to Adoptium.

[rahlk]

Context for whoever picks this up: the PyPI-distribution route (#161, #162) has been closed as won't-do — the Java backend was deliberately reverted to the bundled jar because of GraalVM issues. So the JDK question does not get solved as a side effect of moving Java to a native PyPI binary; it needs solving on its own terms here.

Confirmed still live: cldk/analysis/java/codeanalyzer/_jdk.py fetches and caches a pinned Temurin (JDK_RELEASE = "jdk-21.0.5+11") under the per-project cache dir, with no probe for a suitable system JDK.