Bundle a Temurin JRE in the VS Code extension

[lwrage]

Stacked on #10: this branch builds on its commits (the advanced OSATE pin and its
scripts/build-test-release changes). Retarget to main once #10 merges.

Why

The extension shipped no Java. It declared redhat.java as an extensionDependency
and launched the server with that extension's tooling JRE, which made our server's
runtime someone else's implementation detail — a change to
javaRequirement.tooling_jre breaks us, and the Java version was outside our
control. The integration tests had to install redhat.java from the Marketplace
just to activate, so the activation suite was this.skip()-gated and passed
silently whenever that failed.

What

• Bundle an Eclipse Temurin 21 JRE and run only that. No discovery, no
  JAVA_HOME/PATH fallback, no override setting. JAVA_TOOL_OPTIONS,
  _JAVA_OPTIONS and JDK_JAVA_OPTIONS are stripped from the server's
  environment — bundling a runtime and then letting the machine inject agents into
  it defeats the point.
• One VSIX per platform (aadl2-<target>-<version>.vsix) for darwin-x64,
  darwin-arm64, linux-x64, linux-arm64, win32-x64 and win32-arm64. A bundled
  runtime cannot be universal. vsce.package.targets selects the set: host by
  default, all for a release.
• One shared download helper, scripts/lib/temurin.sh, used by both bundling
  paths. It adds checksum verification against Adoptium's published digest, which
  the osate-cli path never had.
• Activation no longer rejects when the runtime cannot start; it reports the
  failure, so a package installed for the wrong platform says so instead of
  appearing as a generic activation error.
• The release workflow validates all six packages — plug-in count, bundled
  runtime, declared target platform, pre-release marker — before publishing
  anything, and publishes them in a single vsce publish. Marketplace versions are
  immutable, so a partial publish would strand platforms on different versions.

Trade-offs

• Each VSIX grows from ~78 MB to ~121 MB.
• Alpine, 32-bit ARM and web clients are offered no package, because no untargeted
  fallback is published. Documented in the README, CHANGELOG and RELEASING.

Verified locally

• ./scripts/build-test-release --skip-osate --skip-cli green, with 29
  integration tests passing on the bundled JVM under --disable-extensions —
  that suite previously skipped in its entirety.
• All six targets stage with the right architecture; darwin-x64 is Mach-O
  x86_64, win32-* get java.exe.
• code --install-extension into a clean profile: runtime/bin/java and
  lib/jspawnhelper keep mode 755 and the JRE runs, so nothing relies on a
  chmod at startup.
• The release workflow's check step, extracted and run against real VSIXs: passes,
  and fails correctly on a missing target and on a pre-release mismatch.
• osate-cli packaging still produces a working bundled-runtime tarball.

Two traps worth knowing, both documented in the code: maven-clean follows the
runtime symlink and deletes the cached JRE even with followSymlinks=false, and
unzip -l | grep -q fails under pipefail because the SIGPIPE kills unzip.

🤖 Generated with Claude Code