Bundled desktop JRE is Java 11 while engine compiles to Java 17; afterEclipseImport never runs

[soloturn]

Two real, pre-existing issues found while reviewing #737 (the Groovy → Kotlin DSL conversion), both left unfixed there since fixing either would be an actual behavior change, not just a DSL translation — confirmed present in the original Groovy build too, so neither is something the conversion introduced.

Bundled desktop JRE is Java 11, engine targets Java 17

destination-sol-jre.gradle/.gradle.kts downloads a BellSoft Liberica JRE pinned to 11.0.19+7 for distZipBundleJREs/distBundleJREs. Meanwhile destination-sol-java.gradle/.gradle.kts compiles with options.release = 17. A Java 11 JRE cannot load Java 17 class files — it fails with UnsupportedClassVersionError at startup. Anyone actually running the bundled-JRE desktop distribution (as opposed to running from source, or distZipUnbundledJRE against a system JRE) hits this.

Fix: bump jreVersion (and the corresponding BellSoft download URL) to a Java 17 release.

afterEclipseImport task is never wired into the Eclipse import lifecycle

desktop/build.gradle/.gradle.kts registers an afterEclipseImport task that patches .classpath to add an assets source entry, but nothing (dependsOn, finalizedBy, eclipse.synchronizationTasks) actually triggers it. The task name matches a hook that the older Spring Tool Suite (STS) Gradle plugin used to auto-invoke after project import, but the current standard Eclipse Gradle tooling (Buildship) doesn't look for or run a task by that name — so this has likely been dead since the project moved to Buildship, silently leaving .classpath without the assets entry after an Eclipse import.

Fix: wire it up via eclipse.synchronizationTasks (Buildship's supported mechanism), or fold its logic directly into the existing eclipse { project { file { whenMerged { ... } } } } block instead of a separate task.