Polish Java / JVM consumption surface for 0.19.0 (#400)

[michalharakal]

Refs #400.

Summary

Makes the three new Kotlin surfaces from 0.19.0 (`StableHloConverterFactory`, `TokenizerFactory`, the `TensorEncoding` metadata helpers on `TensorSpec`) cleanly callable from Java, adds `skainet-backend-api` to the BOM so Java consumers get pinned versions for every module, and extends `skainet-test-java` with a `ReleaseApiJavaTest` that exercises each entry point from real Java code — so any future regression surfaces at compile time instead of at runtime in a downstream consumer's project.

The gap before this PR

`SKaiNET` (the pre-existing `sk.ainet.java.SKaiNET` facade in `skainet-backend-cpu/jvmMain`) was already nicely annotated with `@JvmStatic` / `@JvmOverloads`, and `skainet-test-java` already had 3 Java test files exercising `SKaiNET.context()`, `tensor()`, `zeros()`, model building, and tensor ops. But none of the 0.19.0 additions had gotten the same treatment:

1. `StableHloConverterFactory` — `public object`, no `@JvmStatic`. Java call sites had to write `StableHloConverterFactory.INSTANCE.createExtended()`.
2. `TokenizerFactory` — same shape, same problem: `TokenizerFactory.INSTANCE.fromGguf(...)`.
3. `TensorSpecEncoding.kt` — file of top-level extension functions. Java callers saw the default synthetic class name `TensorSpecEncodingKt`, producing verbose sites like `TensorSpecEncodingKt.getTensorEncoding(spec)`.
4. BOM was missing `skainet-backend-api` (the neutral module from Add skainet-backend-api module (#468) #470) so Java consumers depending on the BOM didn't get a pinned version for it.

The five commits

1. `1253b42f` — BOM adds skainet-backend-api

`skainet-bom/build.gradle.kts` gains one `api(project(":skainet-backends:skainet-backend-api"))` constraint, grouped with `skainet-backend-cpu` under the backend section. BOM still builds clean.

2. `25be9dc7` — @JvmStatic on StableHloConverterFactory

Every factory method gets `@JvmStatic`, and `createCustom` gets `@JvmOverloads` so every parameter default generates a JVM overload. The annotations live in `commonMain` — Kotlin 1.9+ accepts JVM-specific annotations in common code and treats them as no-ops on non-JVM targets. Verified across jvmTest, wasmJsTest, wasmJsBrowserTest, wasmWasiTest, wasmWasiNodeTest, macosArm64Test, and iosSimulatorArm64Test.

3. `1ebd21b4` — @JvmStatic on TokenizerFactory

Same treatment for both factory entry points (`fromGguf(Map)`, `fromTokenizerJson(String)`). This is the canonical entry for the new Qwen byte-level BPE + SentencePiece tokenizers from #463 / #464, so it's a meaningful Java-side win: Qwen / LLaMA / Gemma / TinyLlama tokenization without Kotlin-specific interop glue.

4. `76cfea29` — @file:JvmName("TensorSpecs") on TensorSpecEncoding.kt

Java callers now see `TensorSpecs.getTensorEncoding(spec)` / `TensorSpecs.withTensorEncoding(spec, TensorEncoding.Q8_0.INSTANCE)` / `TensorSpecs.inferTensorEncoding(tensorData)`, matching the name used in the Kotlin extension-syntax receiver. Kotlin call sites stay unchanged (they go through the extension syntax either way). Pure JVM-side binary-name change.

5. `d6e5f226` — ReleaseApiJavaTest

New JUnit5 Java test covering all three surfaces:

```java
// 1. Converter factory via idiomatic static form
StableHloConverter converter = StableHloConverterFactory.createExtended();

// 2. Tokenizer factory via idiomatic static form (error-path
// invocation — cleanest way to prove static dispatch without a
// real GGUF fixture in the test classpath)
assertThrows(UnsupportedTokenizerException.class,
() -> TokenizerFactory.fromGguf(Collections.emptyMap()));

// 3. TensorSpecs facade for the TensorEncoding helpers
TensorSpec annotated = TensorSpecs.withTensorEncoding(
bare, TensorEncoding.Q8_0.INSTANCE);
assertSame(TensorEncoding.Q8_0.INSTANCE,
TensorSpecs.getTensorEncoding(annotated));
```

`skainet-test-java/build.gradle.kts` gains `skainet-compile-hlo` and `skainet-io-core` on the test classpath so the new test can reference the factories and encoding helpers.

Test plan

• `./gradlew :skainet-bom:build` — green (BOM constraint resolves)
• `./gradlew :skainet-compile:skainet-compile-hlo:allTests -x kotlinWasmStoreYarnLock` — green across jvmTest, wasmJsTest, wasmJsBrowserTest, wasmWasiTest, wasmWasiNodeTest, macosArm64Test, iosSimulatorArm64Test
• `./gradlew :skainet-io:skainet-io-core:{jvmTest,compileKotlinWasmJs,macosArm64Test}` — green
• `./gradlew :skainet-lang:skainet-lang-core:{jvmTest,compileKotlinWasmJs,macosArm64Test}` — green
• `./gradlew :skainet-test:skainet-test-java:test` — green, including the 4 new tests in `ReleaseApiJavaTest` alongside the 3 pre-existing test classes
• CI: full multiplatform build

Net effect for Java consumers of 0.19.0

A Java app pulling in the 0.19.0 BOM can now:

```java
// Execute tensors (pre-existing)
var ctx = SKaiNET.context();
var t = SKaiNET.zeros(ctx, new int[]{2, 3}, DType.fp32());

// Export via StableHLO (0.19.0)
var converter = StableHloConverterFactory.createExtended();
var module = converter.convert(graph, "main");

// Tokenize for Qwen / LLaMA / Gemma / TinyLlama (0.19.0)
var tokenizer = TokenizerFactory.fromGguf(ggufFields);

// Read / write TensorEncoding metadata (0.19.0)
var encoding = TensorSpecs.getTensorEncoding(spec);
var annotated = TensorSpecs.withTensorEncoding(
spec, TensorEncoding.Q8_0.INSTANCE);
```

No `.INSTANCE.` noise, no `TensorSpecEncodingKt` naming, no manual version pins for `skainet-backend-api`.

🤖 Generated with Claude Code

[github-actions]

📖 Documentation Preview

The documentation has been built successfully for this PR.

Generated Files:

• Operator documentation: docs/modules/operators/_generated_/
• JSON schema output: operators.json

Artifacts:

• Download the documentation-preview-498 artifact to view the complete documentation locally.

This comment will be updated automatically when the PR is updated.