Decouple database and collection commands from rendered tree nodes

Problem

Database and collection commands generally accept concrete tree item instances. Surfaces such as Cluster Dashboard and Collection View can identify a target from stable context (clusterId, database name, collection name) but still have to recover a materialized tree node before invoking those commands.

That makes a valid action depend on presentation state. The target may exist on the server and be visible in a webview, while its command fails because the corresponding tree branch has never been expanded, was refreshed, changed layout, or was evicted from a provider cache. Asking the user to expand a separate sidebar hierarchy repairs internal bookkeeping rather than the database operation they requested.

PR #823 exposes this in Cluster Dashboard. Its inventory comes directly from the server, but Create Collection and delegated row actions call resolveNamespaceNode. Missing nodes currently surface inconsistently: create actions become non-modal errors, while row commands show a modal asking the user to expand the cluster.

Issue #868 tracks the narrower Collection View import/export instance of the same architectural dependency.

Desired outcome

Database and collection commands can run from stable operation context without requiring a rendered TreeElement. Tree nodes remain adapters for tree-originated invocations, not the command contract itself.

The shared context should carry, as applicable:

• stable clusterId
• owning viewId or provider identity
• database and collection names
• connection/session access
• command source and telemetry correlation

Command handlers should resolve the database operation from that context. Tree-specific presentation such as temporary descriptions or reveal behavior should be optional.

Scope

Audit commands that act on databases or collections, including create, delete, copy/paste, import/export, shell, playground, reference-copying, and Collection View hand-offs. Identify which genuinely need tree presentation state and migrate the rest to stable context.

Coordinate with #868 rather than solving Collection View import/export twice.

Acceptance criteria

• A database or collection action can run when its target exists but its tree hierarchy has never been expanded.
• Actions continue working after tree refresh, provider layout changes, and cache eviction.
• Connections, Azure Resources, Atlas, Kubernetes discovery, and Local Quick Start retain correct identity and command behavior.
• Tree-originated commands preserve existing confirmations, progress, telemetry, and refresh behavior.
• Webview callers receive one consistent actionable error when the stable target itself no longer exists.
• Focused tests cover unexpanded-tree and cache-miss paths for each materially different provider layout.

Start by auditing database and collection command handlers that use resolveNamespaceNode, with PR #823 and issue #868 as context. Trace stable context from Cluster Dashboard and Collection View callers, then use the acceptance criteria to define focused tests for unexpanded trees and cache misses across provider layouts; done means commands no longer require rendered tree nodes while existing behavior is preserved.