Audit cache key generation strategy

[chidozieononiwu]

As follow up to discussions around #2195
Audit the strategy used for creating cache keys, tools / service wide.

Standardize on canonical identifiers before key generation.
Use resolved subscription ID, tenant ID, resource ID, endpoint URI, and auth mode rather than raw user input where possible. Right now some services key by the raw subscription string while others key by resolved IDs. That creates duplicate caches for the same logical resource and makes invalidation harder.

Introduce typed key builders for common cache categories.
Stop having services invent layouts inline. Add small helpers for patterns like resource list keys, single resource keys, SDK client keys, and external content keys.

Define the required cache dimensions explicitly.
For each cache category, decide what must be part of the key for correctness tenant, cloud, auth method, subscription, resource scope, endpoint.

Add a version token to the strategy.
A lightweight version prefix or versioned typed-key helper to evolve the strategy safely without relying only on TTL expiry.

Separate client-instance caching from data-result caching as a first-class concept.
Client caches depend on auth context and environment. Data caches depend on query scope and resource identity.

Decide how HTTP mode should actually support caching before expanding the strategy.
The current HTTP cache implementation is still a stub inhttps://github.com/microsoft/mcp/blob/main/core/Microsoft.Mcp.Core/src/Services/Caching/HttpServiceCacheService.cs is remote mode is per-user, shared, or intentionally uncached.

[github-actions]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @alzimmermsft @anannya03 @anuchandy @g2vinay @microsoft/azure-mcp @xiangyan99.