Map points, ids and vectors onto Qdrant's protobuf messages

[tonytonycoder11]

Third slice of #52, after #54 and #58. Points, ids and vectors — the mapping where the two models stop
lining up.

The three places they disagree

• A point id is a uint64 and Java has no unsigned long. ULong.MAX_VALUE goes out as -1 and
  comes back as ULong.MAX_VALUE. That is correct and looks wrong, so the test asserts both halves
  rather than only that the round trip closes — otherwise a symmetric bug would pass.
• VectorData.Named is recursive; the wire form is not. map<string, Vector> holds one dense,
  sparse or multi variant per entry, with no way to nest another map. Flattening it would store a
  different collection than the caller described, so it is refused and the message names the offending
  key.
• VectorData.Raw has no equivalent. It exists so the REST engine can carry a JSON shape this
  client does not model yet, which is an escape hatch protobuf does not have.

A trap worth naming

Writes send Vector; reads come back as VectorOutput, a different message with the inference
variants (Document, Image, InferenceObject) dropped, because a server never echoes back a request
to embed something. The round-trip test deliberately goes out as one and back as the other, since
assuming they are interchangeable is exactly the mistake to catch at this layer rather than in the
transport.

Smaller decisions

• An empty payload map reads back as no payload, not an empty object. Absence and emptiness are
  different answers to "what is stored on this point".
• A vector missing from a VectorOutput maps to null rather than an empty dense vector — normal for a
  named-vector collection where only some vectors were written.
• An id Qdrant sends with no variant set throws. That is a broken response, and defaulting it to zero
  would attach the payload to the wrong point.

Thirteen tests. Still no QdrantTransport implementation: filters are the last mapping before the
operations become mechanical.