Decouple Collection View actions from Discovery tree cache lifetime

Problem

Collection View import and export resolve the open collection by locating its CollectionItem in the Discovery View tree cache. This makes a Collection View action depend on the corresponding discovery tree node still existing in the current cached tree.

The lookup starts from a stable clusterId, finds a cached cluster node, then builds and traverses the collection path from that node. It does not rehydrate an unexpanded Discovery hierarchy.

This is a future-work follow-up to #861.

Kubernetes list and tree view switch

Kubernetes supports two renderings beneath a context:

• Tree view: source -> context -> namespace -> cluster
• List view: source -> context -> cluster, with namespace shown in the cluster description

Changing the mode performs a whole Discovery View refresh. That clears the parent and node cache. The same cluster retains a stable clusterId and terminal tree-ID suffix, so lookup works again once its path has been expanded in the newly selected layout.

However, an already-open Collection View can no longer resolve the collection immediately after the switch, because the new tree hierarchy has not yet been recreated and cached. Import and export can therefore fail until the user expands the relevant source, context, and cluster again.

Atlas impact

Atlas is also shipping a list and tree presentation. Its tree cache will be invalidated by equivalent full-tree refreshes, creating the same Collection View cache-lifetime dependency. Atlas additionally needs its stable clusterId to remain resolvable to the rendered cluster node in both modes.

Desired outcome

Collection View actions must not require the target collection to be present in the Discovery tree cache. They should resolve or construct the required operation context from stable identifiers and connection/session state, rather than from a cached CollectionItem.

The replacement design should:

1. Support Connections, Azure Resources, Atlas, and Kubernetes discovery sources.
2. Work before a discovery hierarchy has been expanded and after a full Discovery View refresh.
3. Preserve import/export progress, telemetry, command correlation, and error handling.
4. Keep the tree node optional, limited to tree-specific presentation only if needed.
5. Define a stable provider contract for resolving a collection from clusterId, database name, and collection name without relying on cached tree IDs.

Acceptance criteria

• Collection View import and both export actions work after switching Kubernetes between list and tree mode, without re-expanding the discovery hierarchy.
• The same actions work for Atlas in either presentation mode and after a full Discovery View refresh.
• The actions work when the Collection View was opened from a discovery provider but the corresponding cluster node is absent from the cache.
• Focused tests cover the cache-miss path and both Kubernetes layouts.
• Focused tests cover the Atlas layout(s) and stable clusterId resolution.