chore: shrink datatransferproject/dev image and fix bundled Gradle mismatch

[alexeyqu]

Summary

• The datatransferproject/dev image bundled Gradle 8.10.2, which is never invoked (the entrypoint is ./gradlew, wrapper-pinned to 6.9.2) and can't even build this project -- build.gradle uses the legacy maven plugin, removed in Gradle 7+.
• Base image swapped to eclipse-temurin:11-jdk-jammy, with the wrapper-pinned Gradle 6.9.2 resolved and cached into an image layer at docker build time, rather than downloaded on first docker run.
• 708MB -> 631MB (11% smaller), while fixing a latent version mismatch and remaining fully offline-capable after build.

Notable decisions / tradeoffs

• Why temurin and not just a smaller gradle:* tag: the project's build only works under Gradle 6.9.2 (wrapper-pinned). No official gradle:6.9.2-* variant is smaller than the current image anyway (727MB) -- baking the correct wrapper distribution onto a bare JDK base beats bundling a whole (and in this case wrong) Gradle install.
• Why eclipse-temurin is not a new trust surface: confirmed via matching JAVA_HOME, layer signatures, and entrypoint script fingerprint that gradle:8.10.2-jdk11 was already built on Temurin -- this just removes a layer of indirection around the same JDK.
• Prewarming vs. leaving the wrapper to download at docker run: resolving at build time keeps the image self-contained/offline-capable and still respects gradle-wrapper.properties as the single source of truth -- no version hardcoded a second time, so Docker's build cache naturally invalidates and re-fetches if the wrapper version changes.
• GRADLE_USER_HOME/volume path unchanged: still /home/gradle/.gradle, so docker-compose.yml and any already-warmed gradle-cache volumes keep working untouched.

Test plan

• docker build succeeds
• ./gradlew --version resolves offline (--network none) against a fresh named volume
• ./gradlew tasks succeeds end-to-end with network available
• Image size confirmed via docker images: 708MB -> 631MB