build: bump google-java-format to 1.28.0 for JDK 22+ compatibility

[nielspardon]

Problem

./gradlew spotlessCheck fails for some contributors with lint errors like:

google-java-format(java.lang.NoClassDefFoundError) com/google/common/base/CharMatcher
removeUnusedImports(java.lang.NoClassDefFoundError) com/google/common/base/Predicate

It does not reproduce in CI or for everyone — only for developers whose Gradle daemon runs on a newer JDK.

Root cause

google-java-format 1.23.0 (pinned to match ktfmt 0.61's bundled version) calls com.sun.tools.javac internals whose signature changed after JDK 21 (e.g. Log$DeferredDiagnosticHandler.getDiagnostics()). When Spotless runs the formatter on JDK 22+, it throws NoSuchMethodError, which cascades into the NoClassDefFoundError on a Guava class as the partially-initialized formatter classes are re-referenced. Guava is fully present on the classpath — it's an initialization failure, not a missing dependency. CI and JDK 17 developers are unaffected because 1.23.0 still works on JDK ≤ 21.

Verified directly against the cached jars:

google-java-format	JDK 17	JDK 21	JDK 25
1.23.0	✅	✅	❌ NoSuchMethodError
1.28.0	✅	✅	✅

Changes

• Bump the Java step's googleJavaFormat 1.23.0 → 1.28.0. 1.28.0 is the newest release that still runs on JDK 17 (1.29.0+ require JDK 21), so it works across JDK 17–25 and keeps matching the daemon/CI toolchain. It produces identical formatting — spotlessApply yields no reformatting diff. This step has its own formatter classpath, independent of ktfmt's bundled copy (used only for Kotlin), so the two versions need not match.
• Pin build-logic's kotlin-dsl compilation to a Java 17 toolchain. Otherwise it emits bytecode for whatever JDK the daemon runs on (e.g. Java 21, class file 65), which a Java 17 daemon cannot load (UnsupportedClassVersionError). Pinning to 17 yields class-61 bytecode that loads on any daemon JVM.
• Size build-logic's Kotlin compile-daemon heap. build-logic is an included build and does not inherit the root gradle.properties, so a cold compile otherwise fails with an OOM / internal compiler error.

Testing

• spotlessCheck passes on JDK 17, 21, and 25 daemons.
• Confirmed by a second contributor (@mbwhite): the lint errors no longer occur.
• No code reformatting introduced by the formatter bump.

🤖 Generated with AI