Cosmos: Eagerly load Partition Key Range Cache

Right now, we load the Partition Key Range cache in `CosmosDriver::execute_operation` IFF one of the following is true:
* PPAF is enabled
* PPCB is enabled
* Session Token Management is enabled **and** the request has no session token provided **and** Gateway v2 is enabled (EVEN if there is no gateway v2 endpoint accessible).

This is inconsistent and difficult to manage. I propose we move it to a different approach and ALWAYS prime the cache during `resolve_container`. However, this does have a memory impact when the number of partitions is large, plus an I/O impact on startup.

Open Question: What, if any, escape hatches do we provide? I'd like to use the simplest option here. One option I was considering was a simple `partition_key_range_cache_mode` that can be `Eager` , `Lazy`, and maybe `Off` (which would cause immediate errors for anything that required it). With the default being `Eager`. We would STRONGLY advise users against using `Lazy` or `Off` without clear guidance (maybe even hide this setting in the "Quirks" feature we keep talking about 🤔 ). If we're going to have a way to turn it off, I'd prefer it be clear and well-documented rather than a magic combination of settings.

Start by reading CosmosDriver::execute_operation and resolve_container to trace when the Partition Key Range cache is currently loaded. Compare the proposed eager priming with the memory impact for large partition counts and startup I/O, then review how PPAF, PPCB, Session Token Management, and Gateway v2 affect the behavior. Done means agreeing on the cache policy and escape hatches, implementing the chosen design, and covering the relevant behavior with tests.

Written by the indexing model from the issue text.