Cosmos: bound streaming ORDER BY continuation token size

Follow-up from the [#4800](https://github.com/Azure/azure-sdk-for-rust/pull/4800) deep review.

A streaming `ORDER BY` continuation token carries **one entry per active partition**, each with its resume values, last RID, and skip count. Token size is therefore `O(partitions × sort-key size)` with no upper bound. A 100-partition container ordering on a long string key can produce a token in the tens of kilobytes, which callers persist and round-trip.

Separately, the token's outer version string stayed `c1.` when the `StreamingOrderedMerge` payload variant was added. That is backward compatible today (an older client rejects the unknown node kind), but it means the version string no longer distinguishes payload capability.

### Scope

- Decide and enforce a maximum encoded token size, with a clear error (or a documented degradation) when exceeded.
- Consider compressing the encoded payload, or truncating/normalizing resume values that exceed a size threshold.
- Decide whether the outer token version should be bumped (or a payload-level version added) now that the client payload set has grown, and document the compatibility contract either way.

### Validation

- A test asserting the token stays under the chosen bound for a wide container with large keys.
- Round-trip tests across the version boundary for whatever versioning decision is made.

Start with the streaming ORDER BY continuation-token encoding and the StreamingOrderedMerge payload variant described in the issue. Review how encoded size and the outer c1. version are currently handled, then examine the requested validation cases: a wide container with large keys and round trips across the chosen version boundary. Done means the size behavior, error or degradation, and compatibility contract are tested and documented.

Written by the indexing model from the issue text.