kdrant-core declares the JVM and eight Kotlin/Native targets. None of them is Android, the README's
Platforms section never says the word, and no file in this repository mentions R8 or ProGuard. An
Android application that adds kdrant-transport-rest gets the -jvm artifact, which is probably the
right answer, and nothing here has ever confirmed it.

The gap that matters is not the missing target, it is the shrinker. R8 in full mode is what a release
build runs by default, and it removes what it cannot see being used. kotlinx-serialization ships keep
rules and Ktor ships some, so the union may well be enough; whether it is, is not a thing to reason
about from a dependency list. This project already learned the lesson once in the other direction:
example-native-image exists because a GraalVM claim nobody compiled is a claim that quietly stops
being true. R8 is the same class of tool with a worse failure mode, because the break lands at runtime,
in a release build, on somebody's phone, and never in CI.

Two smaller things sit behind it. The JVM engine is Ktor CIO, and Android has an engine of its own that
most Android codebases already carry. And a minimum SDK is a fact a consumer needs before they try, not
after their build fails on a desugaring error.

One decision to settle rather than assume: whether to publish androidTarget() as a tenth artifact,
which is a publication surface and a set of consumer rules maintained forever, or to state that the JVM
artifact is the Android one and ship the keep rules beside it. The second is a file and a paragraph and
is very likely the right answer, but it is worth writing down which was chosen and why.

Exit criterion: a sample Android application built in release with R8 in full mode runs a search against
a real Qdrant on an emulator in CI on every push, the README names the minimum SDK and whatever a
consumer has to add, and the choice between an Android artifact and the JVM one is recorded with its
argument.