Cosmos: Decide throughput error contract

### Feature Summary

Define and test the public terminal result when a throughput-offer lookup remains empty after container metadata is refreshed and queried again.

### Feature Description

Container recreation recovery now refreshes stale container metadata and retries an empty throughput-offer query once. If the refreshed query still finds no offer, the SDKs currently differ:

- Rust returns `None` for throughput reads and `404/20301 CLIENT_NO_THROUGHPUT_OFFER_FOR_RESOURCE` for replacement;
- Python and Java expose a client-generated `404/10004`-style offer-not-configured result.

Decide whether Rust should preserve its current contract or align with the other Cosmos SDKs. The decision should distinguish an expected absence of dedicated throughput from a stale-RID recovery failure and should not introduce additional unbounded retries.

Acceptance criteria:

- the terminal contract is explicitly decided and documented;
- throughput reads and replacements have focused tests for both recovery and exhausted lookup;
- any public behavior change includes the appropriate changelog/API review;
- the implementation performs at most one recreation refresh before returning the terminal result.

### Use Case

Applications need a stable, documented way to distinguish successful stale-container recovery from a resource that genuinely has no dedicated throughput offer.

### Alternatives

Keep Rust's existing `None` / `404/20301` behavior and document the intentional cross-SDK difference, or align both operations with a client-generated `404/10004` contract.

### Additional Context

Follow-up to #4427 and the recreation work completed by #5197 and PR #5219.

Start by reading the container recreation recovery work from #4427, #5197, and PR #5219, then trace the throughput read and replacement paths described here. Decide and document the terminal contract for recovery and exhausted lookup, add focused tests for both cases, and verify that only one recreation refresh occurs before returning. Include the required changelog or API review for any public behavior change.

Written by the indexing model from the issue text.