feat(kernel): JVM ServiceLoader auto-discovery for KernelProvider

[michalharakal]

Summary

• Adds KernelServiceLoader (skainet-backend-api/jvmMain) — a JVM-only object exposing discover() and installAll() that scan META-INF/services/sk.ainet.backend.api.kernel.KernelProvider and register every declared provider into KernelRegistry.
• Ships JVM service factories ScalarKernelProviderFactory / PanamaVectorKernelProviderFactory in the cpu backend, plus the META-INF service file listing both. The factories delegate to the existing singletons via KernelProvider by <singleton> — ServiceLoader needs a public no-arg constructor that Kotlin object doesn't expose, so the wrappers are the standard workaround.
• Updates the KernelRegistry kdoc to document the new discovery path.

Why now

The previous SPI doc deferred this until a second concrete provider existed. With Panama landing in #557, that condition is met — single-provider auto-discovery would have been ceremony for nothing.

Why JVM-only

ServiceLoader doesn't exist on Kotlin/Native, JS, or Wasm targets. Those platforms continue to call KernelRegistry.register(...) directly. Manual registration is still supported on JVM too — useful for tests, and for callers that want to pin a specific provider.

Test plan

• ./gradlew :skainet-backends:skainet-backend-cpu:jvmTest — all 213 tests pass; new KernelServiceLoaderTest adds 4 (discover finds both, installAll registers in priority order, bestAvailable picks Panama on test JDK, idempotent reinstall).
• No regressions in existing kernel tests (KernelRegistryTest, ScalarMatmulKernelTest, PanamaVectorMatmulKernelTest, PanamaVectorKernelProviderTest) — all green.

Caller-facing usage

Typical JVM startup wiring becomes:

KernelServiceLoader.installAll()
val kernel = KernelRegistry.bestAvailable()?.matmulFp32()
    ?: error("no FP32 matmul kernel available")

Follow-ups (M5)

• Route DefaultCpuOpsJvm.matmul through KernelRegistry — calling KernelServiceLoader.installAll() once at backend init and looking up bestAvailable().matmulFp32() instead of calling JvmVectorKernels.matmulFloat* directly. Caveat from bench(kernel): KernelMatmulBench — scalar vs Panama (M5 evidence) #558: until PanamaVectorMatmulKernel gets cache-blocking, routing will show a 14–52% regression at 512²/1024² vs the existing matmulFloatBlocked path. Recommended order: port tiling first, then route.
• Native kernel provider (priority 100, FFM-based).
• Quant kernel SPIs (Q4_K / Q6_K / Q8_0 — JVM-only because of MemorySegment).

🤖 Generated with Claude Code