M25 · Build the core everywhere Kotlin does

[tonytonycoder11]

Closes #23. #63 is merged and this branch carries it, so the diff below is the multiplatform work alone.

kdrant-core now compiles for the JVM and for eight Kotlin/Native targets: iosArm64,
iosSimulatorArm64, iosX64, macosArm64, macosX64, linuxArm64, linuxX64, mingwX64. What made
that a two-file change rather than a rewrite is the transport seam: the models, DSLs, error hierarchy
and client logic never knew there was a wire, so moving them into commonMain was a git mv and the
compiler had nothing to say.

Kotlin/JS was added and then dropped. Dependency review failed the branch on a high-severity
advisory in brace-expansion, reached through the yarn.lock that the JS target's Karma and webpack
test tooling needs. Nothing published contains that package, so the finding could have been suppressed.
It is a better question than that: kdrant-core on JS is models, a DSL and a transport interface with
no implementation behind it, because Ktor CIO and grpc-java are both JVM-only. The target was carrying
the repository's only npm dependency graph in exchange for a library nobody can currently use. One line
brings it back the day someone writes a JS engine.

Against the exit criterion — "kdrant-core builds for commonMain with no java.* on the common
path, and the JVM artifact stays source-compatible":

• commonMain compiles for all nine targets. That is the compiler's own proof about java.*; there is
  nothing to grep for.
• The JVM api dump is unchanged, byte for byte. apiCheck reports no diff.

Two of the four items in the issue were already done. java.util.UUID and java.time.Instant do
not appear in the core at all — a point id is a ULong or a string, and a datetime bound is the RFC
3339 text Qdrant parses — so neither ever needed a JVM type.

The third was real and is the one declaration this migration had to split. Only the JVM publishes an
IO dispatcher, which is the right default for a client that blocks on a socket rather than a CPU.
Kotlin/Native has one that the coroutines library still keeps internal, so it gets Dispatchers.Default
and the KDoc says why. Passing your own dispatcher works as before.

The fourth is deliberately not here. "The Ktor engine parameterised per target" would mean picking
and testing a Ktor engine per platform. The engines stay JVM-only; a multiplatform consumer shares its
models and query building and supplies its own transport. That is its own piece of work, and the exit
criterion is about the core.

The artifact layout changes, and it is why this is 2.0 and not a minor. kdrant-core now carries
Gradle module metadata and the JVM classes live in kdrant-core-jvm. A Gradle build resolves the
variant from the same coordinate and sees nothing; a Maven build naming kdrant-core gets no classes.
The BOM constrains both and STABILITY.md says so.

Three build surfaces move with it.

• Releases build on macos-latest. No Linux host compiles the Apple targets, and one that skipped them
  would publish a release quietly missing its iOS klibs. The linked-artifacts step also learns that the
  JVM jar is now kdrant-core-jvm-<version>.jar, which it would otherwise fail to find.
• CI gains an Apple targets job on macOS, for the same reason: without it an iOS break is first seen
  at release.
• kdrant-core's -javadoc.jar holds Dokka HTML. The Dokka Javadoc generator refuses a multiplatform
  project outright, and Maven Central asks for a jar rather than for Javadoc.

Tests. The existing eighty stay on the JVM, where JUnit 5 and kotest-property live; rewriting them
to kotlin.test would run the same assertions in more places against platform-independent code. What
runs everywhere instead is a commonTest suite aimed at what could actually differ: the hand-written
serializers, a point id above Long.MAX_VALUE, an integer payload value above 2^53, and the config's
validation. Verified locally on the JVM, linuxX64, macosArm64 and iosSimulatorArm64.