fix: PartitionKeyRangeCache uses database RID instead of container RID in pkranges requests

[SillyZir]

Summary

Adds documentation for the 401 (Unauthorized) error caused by a known PartitionKeyRangeCache RID mismatch bug (#5734), without modifying any existing documentation.

Problem

Users hitting intermittent 401 errors from pkranges requests have no guidance in Exceptions.md. The root cause — database RID being substituted for container RID in the request URL while the auth header is signed against the correct container RID — is non-obvious and difficult to diagnose without knowing what to look for in diagnostics.

Why a docs-only change

This is an additive documentation improvement, not a code fix. The underlying SDK bug is tracked in #5734. This PR gives users encountering the symptom (401 on pkranges) a clear explanation of the cause, how to confirm it via diagnostics, and a link to the tracking issue — reducing confusion about whether the 401 is a configuration error or a known SDK issue.

No existing content is removed or modified. The new section is appended after the existing 404 SubStatusCode guidance.

Changes

• Added ### 401 (Unauthorized) from PartitionKeyRangeCache using incorrect RID section to Exceptions.md
• Preserved all existing 404 SubStatusCode documentation, code examples, and guidance unchanged

Impact

Users experiencing this intermittent 401 now have a documented explanation and diagnostic steps directly in the exceptions reference. No SDK code, tests, or public API surface affected.

[renshao]

This PR feels a bit strange. There's no actual C# code change, just a markdown file change. I doubt this changes the current code logic at all.

[SillyZir]

Good catch — you're right that this PR doesn’t change runtime behavior.

The goal here is to document a specific failure mode that isn’t obvious from the current error surface.

In this case, the 401 originates from a RID mismatch (database RID being used instead of container RID in pkranges requests), which ends up looking like a generic authorization issue from the outside.

Without this context, it’s difficult to trace — especially since the failure path involves RID resolution + auth header construction rather than a direct SDK error.

So this PR is scoped to improving the diagnostics and making that failure mode explicit for anyone hitting it.

Happy to adjust scope or move this if there's a more appropriate place for it.

[azure-pipelines]

Azure Pipelines:
2 pipeline(s) require an authorized user to comment /azp run to run.

[SillyZir]

Closing this—after reviewing, this doesn’t fully address the issue. Will revisit with a more precise fix.