Cosmos Driver: Wire PartitionKeyRangeCache into CosmosDriver

[simorenoh]

The driver has a fully implemented PartitionKeyRangeCache (driver/cache/partition_key_range_cache.rs) with resolve/lookup logic, incremental refresh via change
feed, and comprehensive unit tests — but CosmosDriver doesn't hold an instance of it. The cache was built and tested in isolation (#4007, #4087) but never wired
into the driver struct.

This blocks query operations, change feed, and full feed range cutover from being routed through the driver.

What needs to happen

1. Add PartitionKeyRangeCache field to CosmosDriver, initialize it in new().
2. Add CosmosOperation::read_all_pk_ranges(container) factory method — the cache needs a fetch closure that calls the /pkranges endpoint. This operation uses
   OperationType::ReadFeed with ResourceType::PartitionKeyRange. The PartitionKeyRangeReference and PkRangesResponse types already exist.
3. Expose a public method on CosmosDriver: pub async fn resolve_routing_map(
   &self,
   container: &ContainerReference,
   force_refresh: bool,
   ) -> azure_core::Result<Arc>

This method builds the fetch closure (using self.execute_operation() internally) and delegates to PartitionKeyRangeCache::try_lookup().
4. Make ContainerRoutingMap public (currently pub(crate) in driver/cache/container_routing_map.rs).

Who needs this

• query_items — needs the routing map for cross-partition fan-out and partition-scoped queries
• Feed range methods — read_feed_ranges and feed_range_from_partition_key currently use the SDK-side routing map as a workaround (PR [Cosmos] Feed Range API #3987); should switch to the
  driver's cache
• Change feed — will need the routing map for partition-scoped consumption

Context

See the Infrastructure Prerequisites section in the SDK-to-Driver Cutover Guide for full details