Use stable clusterId matching for Discovery View cache lookups

[tnaum-ms]

Summary

Discovery View currently resolves cached cluster nodes by removing the discovery-provider prefix from clusterId and returning the first cached tree node whose ID ends with the remaining suffix.

This works only when every discovery provider preserves that exact suffix as the final component of its treeId. It also leaves a theoretical collision risk because the suffix search spans the whole Discovery View cache rather than matching the provider-prefixed stable identity.

Current behavior

DiscoveryBranchDataProvider.findClusterNodeByClusterId():

1. Splits clusterId at the first _.
2. Builds /<unprefixedClusterId>.
3. Calls the global cached-node suffix lookup.
4. Returns the first match without verifying the node's stable clusterId.

The immediate Atlas compatibility issue is being handled separately by aligning Atlas cluster tree leaves with the existing stable-suffix convention.

Proposed future work

Investigate replacing or augmenting suffix lookup with an exact stable-identity lookup:

• Search only cluster tree elements.
• Compare node.cluster.clusterId with the complete requested clusterId.
• Alternatively, scope suffix lookup to discoveryView/<providerId>/ and verify the matched cluster identity.
• Preserve the current cache-lifetime behavior; do not force expansion of every discovery provider.

Benefits

• Avoid cross-provider suffix collisions.
• Decouple stable resource identity from visual tree hierarchy.
• Allow discovery providers to evolve tree/list layouts without duplicating the stable suffix in the leaf ID.
• Better enforce the existing dual-ID contract: clusterId for identity and caches, treeId for tree position.

Acceptance criteria

• Cached clusters resolve by complete stable identity or by a provider-scoped, identity-verified lookup.
• Azure, Kubernetes, and Atlas Discovery layouts continue to resolve collections.
• Duplicate suffixes in different discovery-provider subtrees cannot resolve to the wrong cluster.
• Uncached-cluster behavior remains explicit and does not trigger broad provider expansion.