PKRange resolution API follow-ups from PR #4342

[simorenoh]

Follow-up work items from the review of #4342 (Route PKRange resolution through driver).

1. Prevent empty routing maps in the driver PKRange cache

The driver's PartitionKeyRangeCache can fall back to an empty ContainerRoutingMap on service or parse failures. A valid container always has at least one partition key range, so an empty result should be treated as a resolution failure — not silently cached. The SDK currently works around this with retry-then-error logic in read_feed_ranges() and feed_range_from_partition_key(), but the root fix belongs in the driver.

Files:

• sdk/cosmos/azure_data_cosmos_driver/src/driver/cosmos_driver.rs (resolve_all_partition_key_ranges, resolve_partition_key_ranges_for_key)
• sdk/cosmos/azure_data_cosmos/src/clients/container_client.rs (empty-cache workarounds in read_feed_ranges and feed_range_from_partition_key)

2. Replace feed_range_from_partition_key with FeedRange::for_partition_key

ContainerClient::feed_range_from_partition_key() currently resolves the physical partition that currently contains a given partition key, which is incorrect — physical partition assignments change during splits/merges. The PK-to-FeedRange mapping should be purely hash-based with no I/O. Replace this with a FeedRange::for_partition_key() constructor that computes the EPK hash directly, aligning with the Python and Java SDKs.

File: sdk/cosmos/azure_data_cosmos/src/clients/container_client.rs

3. Use FeedRange terminology in driver PKRange resolution APIs

The driver's public resolve_all_partition_key_ranges() and resolve_partition_key_ranges_for_key() expose raw PartitionKeyRange objects. As FeedRange moves to the driver for feed operations, these APIs should return FeedRanges instead. The driver should be the only component that sees physical partition metadata (PK Range ID); everything above it should work with FeedRanges.

File: sdk/cosmos/azure_data_cosmos_driver/src/driver/cosmos_driver.rs

4. Add unit tests for driver PKRange resolution methods

resolve_all_partition_key_ranges() and resolve_partition_key_ranges_for_key() have non-trivial logic (full vs. prefix key behavior, force_refresh interaction, empty-cache fallback) but no unit tests. Add tests covering:

• Full keys — single range returned via point lookup
• MultiHash prefix keys — multiple overlapping ranges returned
• Failure / empty-routing-map scenarios — verify None is returned, not Some(vec![])

File: sdk/cosmos/azure_data_cosmos_driver/src/driver/cosmos_driver.rs