feat: use --shard-key in search, query, and scroll requests

[generall]

Summary

--shard-key was only applied to upserts and collection creation, so read requests always fanned out across all shards even when a shard key was provided. This applies the shard-key selector to every applicable request so reads target the same shard the data was written to.

Changes

File	Request	Change
src/search/from_args.rs	flag-driven search (QueryPointsBuilder)	selector added in create_request_builder — flows into every batched query, including the exact-search quality pass
src/search/from_config.rs	config-driven search	same, in its create_request_builder
src/scroll.rs	scroll_cursor, sample, random_point	selector added to all three
src/query.rs	get_uuids pre-fetch scroll	selector added so UUIDs are read from the correct shard

All use the same idiom already established in upsert.rs:

if let Some(shard_key) = &args.shard_key {
    request_builder = request_builder.shard_key_selector(vec![Key::Keyword(shard_key.clone())]);
}

Notes

• QueryBatchPointsBuilder has no top-level shard-key selector in qdrant-client 1.18 — the per-query selectors inside the batch are what route the request, which is where they're set.
• When --shard-key is not provided, behavior is unchanged (requests span all shards).
• cargo build passes. Not yet exercised end-to-end against a live sharded collection.

🤖 Generated with Claude Code