Track: vnext-preview emulator query-behavior divergences from classic emulator / live

## Summary

While adding HPK test coverage in #4682, the non-blocking **vnext-preview emulator** CI leg (`Build Test vnext_emulator_stable_vnext_emulator_true`, `test_category="emulator_vnext"`, `ContinueOnError: true`) surfaced two cross-partition query behaviors where the **vnext-preview emulator diverges from both the classic Cosmos emulator and live accounts**. This issue tracks those divergences so we don't lose sight of them.

> [!NOTE]
> This repo (`azure-sdk-for-rust`) is **not** the home of the vnext-preview emulator; these findings likely belong with the Cosmos emulator team. Filing here **for tracking purposes** only, linked from the PR that discovered them.

The affected tests are annotated with the established skip so the vnext leg stays honest:

```rust
#[cfg_attr(
test_category = "emulator_vnext",
ignore = "skipped on vnext emulator: behavioral divergence"
)]
```

They continue to run (and pass) on the blocking classic-emulator legs and on all live-account legs.

## Divergence 1 — cross-partition `FeedScope::range` window ignored (full scan)

- **Test:** `emulator_tests::cosmos_feed_ranges::feed_range_scope_restricts_cross_partition_query`
- **File:** `sdk/cosmos/azure_data_cosmos/tests/emulator_tests/cosmos_feed_ranges.rs`
- **Expected (classic emulator + live):** a cross-partition `SELECT *` scoped to an interior effective-partition-key (EPK) window returns **only** the documents whose EPK falls inside that window. With 40 seeded docs and a wide interior window `[EPK₁, EPK₃₉)`, that is exactly **38** docs (global min/max excluded).
- **Observed (vnext-preview):** the window is ignored and the query **full-scans**, returning all **40** docs.

```
assertion `left == right` failed: SCOPE BUG (wide window): FeedScope::range was ignored
and the query fell back to a full scan. got 40 docs, expected 38.
unexpected(outside window)=["doc-000", "doc-022"]
```

Context: the SDK-side fix for scope restriction (the `x-ms-read-key-type: EffectivePartitionKeyRange` header correction) landed in #4729 and is validated against live accounts, so the divergence is on the vnext gateway, not the client.

## Divergence 2 — advanced cross-partition query servable on an HPK container

- **Test:** `emulator_tests::cosmos_hpk::hpk_query_cross_partition_advanced_not_servable`
- **File:** `sdk/cosmos/azure_data_cosmos/tests/emulator_tests/cosmos_hpk.rs`
- **Expected (classic emulator + live):** because the Rust SDK advertises no cross-partition query features (`SUPPORTED_QUERY_FEATURES=""`), advanced full-container queries over a hierarchical (MultiHash) container are **rejected** with `400/1004 CrossPartitionQueryNotServable`. The test asserts each of the following errors:
- `SELECT DISTINCT c.country FROM c`
- `SELECT VALUE COUNT(1) FROM c`
- `SELECT c.state, COUNT(1) AS n FROM c GROUP BY c.state`
- `SELECT * FROM c OFFSET 1 LIMIT 2`
- **Observed (vnext-preview):** the first query (`SELECT DISTINCT c.country FROM c`) is **served successfully** instead of being rejected, so the `is_err()` assertion fails.

```
cross-partition query should not be servable on an HPK container: SELECT DISTINCT c.country FROM c
```

On the classic emulator and live accounts this same query is rejected:

```
status=CosmosStatus(400/1004 CrossPartitionQueryNotServable) ... operation_type=QueryPlan
```

## Common thread

Both cases are the vnext-preview emulator being **more service-accurate / more capable** than the classic emulator the tests were written against:
- Divergence 1: vnext does **not** apply the interior EPK-range scope → over-returns.
- Divergence 2: vnext **serves** a DISTINCT cross-partition query the SDK expects to be un-servable → under-rejects.

Neither reflects a defect in `azure_data_cosmos`; the tests pass on classic emulator and live.

## Open questions to resolve with the emulator team

- Is Divergence 1 (scope-range ignored → full scan) a known gap in the vnext gateway's cross-partition query planning, or expected?
- Is Divergence 2 (DISTINCT servable on HPK) the intended *future* behavior (i.e., the classic emulator/live are the ones lagging), or a vnext-only artifact? If vnext represents the target behavior, we may eventually want to relax/repoint these assertions once live catches up.

## References

- PR that discovered this: #4682
- Related SDK fix: #4729
- CI leg: `rust - cosmos - weekly` → `Build Test vnext_emulator_stable_vnext_emulator_true` (non-blocking, `ContinueOnError: true`)

Start by running the named tests in sdk/cosmos/azure_data_cosmos/tests/emulator_tests/cosmos_feed_ranges.rs and cosmos_hpk.rs against the vnext emulator, then compare with classic-emulator and live-account results. Resolution requires the emulator team to decide whether both behaviors are gaps or intended changes; done means the behavior and test expectations are aligned, including the existing skips or their removal.

Written by the indexing model from the issue text.