Start Qdrant the way the runner can, not the way Linux can

[tonytonycoder11]

The v2.2.0 release got further and stopped again, one step short.

What passed

The Linux CLI job succeeded, which is the proof the previous fix needed. The binary did this
against a real Qdrant:

copying cli-source -> cli-target (batch 256, recall >= 0.99, checkpoint .../cli.checkpoint)
target: one 4-dimension vector, DOT, 1 shard(s), 1 replica(s)
copied 2 point(s); source 2, target 2
recall 1.0
wrote 64512 bytes to .../cli.snapshot

It created the target from the source's own vectors, copied, verified, snapshotted and scrolled.

What failed

The macOS job, on docker: command not found. A GitHub macOS runner has no Docker, and this repository
already knew that: ci.yml's native-contract-macos job downloads the released Qdrant binary for
exactly this reason. The release workflow was written without reusing that, which is a harness bug and
not a product one.

Starting Qdrant is now its own step that picks by RUNNER_OS: the image on Linux, the released
aarch64-apple-darwin binary on macOS. Proving the binary is a second step that assumes only that
something is answering on 6333.

Proving the binary only on Linux was the other option and is the wrong one. The macOS binary is the one
most people will download onto a laptop, so skipping it would leave the one that matters most as the
only artefact in the release nobody had ever run.

Nothing was published

publish has needs: cli and was skipped, twice now. There is no 2.2.0 on Maven Central and no
GitHub Release. The tag moves to this merge commit when it lands.

[trueup-by-nacode-studios]

This pull request adds no capability the code did not already have.

_{1 file read · 8 ms · against aa58721}