Proposal: single-click to open a Collection View, reuse the existing tab, and add an "Open in New Collection View" action

Summary

This issue proposes a small set of Collection View interaction changes and asks for feedback on the desired final behavior before we implement them.

The behaviors described below were originally implemented inside PR #621 (Kubernetes service discovery). They are general Collection View / tree behaviors rather than Kubernetes-specific, so they were reverted from that PR to keep it scoped to the discovery feature. This issue exists to propose and properly scope them on their own.

Background

While reviewing PR #621 we noticed three related behavior changes to the Collection View that were not part of the Kubernetes feature's stated scope:

1. A single click (single activation) on a collection node opens the Collection View.
2. Opening a collection that already has an open Collection View re-activates the existing tab instead of opening a second one.
3. Opening always reveals the view in the active editor column.

Previously, the Collection View opened from a double click (with debounce) on the Documents child node, and every open created a new tab.

Proposed behavior

• Single click on a collection node opens its Collection View.
• If a Collection View for the same target is already open, bring it to the foreground rather than opening a duplicate tab.
• Add a context-menu action, for example Open in New Collection View, so users can deliberately open a fresh tab even when one already exists.

The third option is the important one: combining single-click open with tab reuse removes the ability to have two views of the same collection side by side. An explicit "Open in New Collection View" action keeps that option available, so the default stays tidy while power users retain control.

Open questions for feedback

1. Should single click open the view, or should we keep activation on a double click? Single click is faster but can feel surprising while browsing the tree.
2. If we reuse the existing tab by default, is Open in New Collection View in the context menu the right escape hatch, or should the behavior be configurable via a setting instead?
3. Should reuse be keyed per collection (current proposal) or per cluster/database as well?
4. Does the Documents child node keep its own open action, or do we retire it once the parent node opens the view directly?

Implementation notes (from the original prototype)

These notes capture the approach that was prototyped, for reference when we scope the work:

• Single-click open: attach a command to the collection tree node's TreeItem pointing at vscode-documentdb.command.containerView.open with the node as the argument.
• Tab reuse: keep a module-level Map<string, CollectionViewController> of active views, keyed by viewId::clusterId::databaseName::collectionName. On open, if a non-disposed controller exists for the key, call revealToForeground(vscode.ViewColumn.Active) and return early; otherwise create the view and register it in the map. Remove the entry in the controller's onDisposed handler.
• Reuse guard: only reuse when there is no initialQuery (a query-seeded open such as "Open in Collection View" from a playground should still start a fresh session/tab).
• New-tab action: the Open in New Collection View command would bypass the reuse map and always construct a new CollectionViewController.

Out of scope

• Final command titles, menu placement, and any setting wording (decide after we agree on the interaction model).

Filed for the 0.10.0 milestone as a follow-up from the PR #621 review.

Start at the collection tree node's TreeItem command wiring and the CollectionViewController lifecycle described in the issue. Resolve the open interaction questions before implementation, then verify single-click opening, reuse of an existing view, and an explicit new-view action without changing query-seeded opens.