fix(java): compile and document as UTF-8, not the platform default

[opendpp-node]

What

Pins the Java build to UTF-8 for compilation and javadoc, instead of inheriting the JVM's platform encoding.

tasks.withType<JavaCompile>().configureEach { options.encoding = "UTF-8" }

plus encoding / charSet / docEncoding on Javadoc.

Why

The generated sources are UTF-8 and carry the contract's own punctuation — em dashes, ellipses, curly quotes — lifted straight from the OpenAPI descriptions. javac and javadoc default to the platform encoding, which on a CI runner is US-ASCII. Every such character becomes ?, javac emits an unmappable character (0xE2) line per occurrence, and — because those are warnings rather than failures — the build stays green while the artifacts ship the corruption.

Observed on opendpp-node's SDK regen verification: hundreds of error-looking lines across src/main and src/test, with the echoed source showing the damage directly:

…/model/AdvisoryItem.java:3: error: unmappable character (0xE2) for encoding US-ASCII
 * … Keys are created in the Client Console (Developers ??? API keys) …
 * … Tenant identity is token-bound ??? it is derived from your API key …

0xE2 is the UTF-8 lead byte for —/…/’.

Impact. Bytecode is unaffected — the damage is in comments — so this is cosmetic. But it is cosmetic on a public artifact carrying the company name: the sources and javadoc jars on Maven Central contain ??? where punctuation belongs, and anyone reading the SDK in an IDE sees it. It also worsens with every typographic character added to the contract; an upstream PR is about to add a Versioning & compatibility section full of them.

Why here rather than in the consumer

opendpp-node's verification job could have set LANG=C.UTF-8 and gone quiet — but this repo is where the Maven artifact is actually published (publish-sdk-java.yml), so that would have hidden the symptom while still shipping corrupted jars. The same corruption also hits anyone building locally on an ASCII-defaulted machine. Fixing the build is the fix; an env var in one consumer is not.

Verification

I could not build locally (no JDK on this machine), so this leans on CI: the Java SDK — generate-drift, version-lock, build, test job compiles src/main and src/test and builds the javadoc jar. The expected signal is the disappearance of every unmappable character line from that job's log — previously hundreds, now none.

Worth a reviewer's eye on one thing I could not check: whether any generated string literal (as opposed to a doc comment) carries non-ASCII. If so this was never merely cosmetic, and the fix matters more than stated above.

Fixes OpenDPP/opendpp-node#1156