M31 · Speak gRPC, without charging anyone who does not

[tonytonycoder11]

Closes #52.

The seam has been in place since the first release and has had one implementation. This is the second,
and what it proves is that the public API really did carry no wire-protocol knowledge: not one line of
kdrant-core changed to add a protocol.

KdrantGrpc(host) returns the same QdrantClient the REST factory does, over Qdrant's Collections,
Points, Snapshots and Health services on 6334. The shared client contract from #62 runs against
both engines, against the same server.

Against the exit criterion — "a kdrant-transport-grpc module passes the same client test suite as
the REST engine, and a REST-only build pulls in none of its dependencies":

• GrpcClientContractIntegrationTest is four lines: it extends QdrantClientContract and picks port
  6334. Same file the REST engine is held to.
• verifyRestEngineFootprint runs on every check and fails if the REST engine's runtime classpath
  resolves anything from io.grpc, com.google.protobuf, io.netty or com.google.guava. It was
  confirmed to fail by adding grpc-stub to the REST module and watching it report the five artifacts
  that arrived, then reverting. The README's footprint table rests on this, so it is checked rather
  than argued.

Where the seam is wider than the protocol. QdrantTransport was shaped by Qdrant's REST API, and
eleven of its operations exist over HTTP only: telemetry, metrics, issues, recoverSnapshot, snapshot
download and upload, and the five shard-scope snapshot operations. Each throws an
UnsupportedOperationException naming itself and naming REST. A snapshot download that returned an
empty flow would be a backup that quietly does not exist, and a KdrantException would have been the
wrong type — nothing failed on the wire, and no retry makes the call work. The three streaming
downloads throw at the call rather than on first collect, so the failure lands where the mistake is.

Health is the one place the protocols disagree and both are right. There is no gRPC /healthz,
/readyz or /livez; there is the standard gRPC health service, which answers one status for the
node. The three probes answer from it and keep the REST engine's false-on-failure contract.

Behavioural parity. Retries mirror the REST engine's, because maxRetries is a client setting and
an engine that ignored it would be a difference nobody asked for. Deadlines are per call rather than
per channel, because requestTimeout is documented as per attempt. gRPC statuses map onto the same
KdrantException hierarchy, including the INVALID_ARGUMENT Qdrant returns on some write paths for a
collection that does not exist.

Tests. Three layers, and only the first needs Docker: the shared contract against a real Qdrant;
GrpcQdrantTransportTest, which runs the transport against fake services over gRPC's in-process
transport and asserts the messages it built and the models it read back; and focused tests for the
error mapping and for the eleven operations that cannot work. Aggregate line coverage is 80.1%.

Also updates the README's module table and footprint paragraph, and the migration guide — "Kdrant does
not speak gRPC" stopped being true.

Merge after #61 and #62.