Gradle migration follow-ups (post-#326)

[pacmano1]

PR #326 migrated the build from Ant to Gradle with output verified byte-identical. To keep that PR reviewable and parity-checkable, several improvements were deliberately deferred. This issue tracks them. Parent: #52.

Build tooling

• Try Gradle 9. The wrapper ships on 8.14.1. Confirm the build runs clean under Gradle 9 and bump when it does. One known item to clear first: a Task.project-at-execution-time deprecation in verifyDistributionPlacement that Gradle 9 warns on and Gradle 10 removes. (raised by @jbeckers in Replace the Ant build with Gradle, output verified byte-identical #326)
• Consider the Kotlin DSL for the build scripts. Currently Groovy; Kotlin is Gradle's official recommendation. (raised in Replace the Ant build with Gradle, output verified byte-identical #326, agreed as a follow-up)
• Clean up stale .gitignore headers. ~111 inert commented section headers (# /client/src/com/...) date to the original 2017 .gitignore and still reference the pre-move layout. Update to src/main/java or drop them. (raised by @jbeckers in Replace the Ant build with Gradle, output verified byte-identical #326)

Dependencies

• Align multi-artifact dependency families with BOMs. The catalog versions every artifact of a family independently, so a bot can bump part of a set and leave it incoherent with nothing to catch it. That is Fix log4j bad versions #389: log4j-api stayed at 2.25.3 while log4j-core and log4j-1.2-api moved to 2.25.4, and the server would not boot. Import platform(libs.<x>.bom) for log4j, jackson, netty, jetty, and the AWS SDK. Constrains versions only, pulls nothing transitively, flat explicit list stays intact.
• Normalize to transitive resolution, one library at a time. The migration intentionally pins a non-transitive, audited set matching the historical vendored jars. Enable transitivity per library during routine version bumps, diff against the flat list, reconcile, re-verify with the parity harness. Flat lists remain better for scanning accuracy, so this is a slow bridge with no deadline. (objection from @jbeckers in the comments)
• CVE burn-down. An initial dependency-check baseline flagged ~54 distinct CVEs across ~46 jars. Start with the one-line, parity-checkable bumps (netty, jackson-databind, pdfbox), then the harder ones: Jetty 9.4.57 (EOL line), MyBatis ([SECURITY] Update MyBatis library #320), Derby, iText -> OpenPDF (Determine if itext is still used and remove it if it is not #289), commons-httpclient -> httpclient5. See also [SECURITY] 4.6.0 release notes should list fixed CVEs #304.
• Adopt byte-identical repackaged jars from Maven Central. 13 vendored jars are content-identical to Central artifacts (the HAPI 2.3 set, jtds, sqlite-jdbc, rsyntaxtextarea, autocomplete) and can be sourced from Central. The 3 genuine forks (javaparser 1.0.8, zip4j 1.3.3, not-going-to-be-commons-ssl) stay vendored.

[jbeckers]

Enable transitive dependency resolution.
I don't understand what this buys us?

I was under the impression that transitive resolution is a place where you start because it's easy, then work to phase out for reasons of security and stablility.
As it is, there's no need for a lock file, nor is there a chance of dependency conflicts or exploits getting in trough transitive dependency updates, etc

[pacmano1]

Fair, and the flat list does help scanning accuracy. But "no chance of dependency conflicts" is what just bit us: main has log4j-api at 2.25.3 while core and 1.2-api went to 2.25.4, Renovate bumped them independently, and the server won't boot. That's #389.

Splitting this item. The real need is alignment for multi-artifact families (log4j, jackson, netty, jetty, aws), which is platform(libs.x.bom) and pulls nothing transitively. Wholesale transitive resolution stays a separate slow item.

We also already have the lock file. verification-metadata.xml checksums every artifact, POMs included.