Cluster Dashboard: add an Operations surface (live currentOp + kill)

Summary

Add a Operations surface to the Cluster Dashboard: a live view of what the cluster is currently doing, with the ability to inspect and terminate a running operation.

This was prototyped inside the Cluster Dashboard PR (#823) but has been pulled out of that PR's scope. The dashboard now leads with the storage/inventory view alone, and Operations should land as its own focused change so it gets the design and review attention it needs.

Why it is worth its own work item

The prototype surfaced several questions that are about operations monitoring specifically, not about the dashboard shell, and each of them deserves a deliberate answer rather than a default:

• currentOp breadth varies by privilege. On a least-privileged connection the chain falls back to the caller's own operations, so a count of "1" can mean one operation on an idle cluster or one of yours among hundreds. The scope has to be reported alongside the number, or the number misinforms.
• killOp is not an acknowledgement. It replies {ok: 1} whether or not anything matched, so the UI can only distinguish requested / cancelled / gone / failed / unverified — it can never truthfully say "the operation has been killed".
• Operations are transient. An operation seen in one poll is usually absent from the next, so a plain snapshot table flickers and cannot be acted on. The prototype kept an observed-operation history keyed by occurrence identity; whether that is the right model is an open design question.
• Command payloads carry customer data. A current operation includes query filter values, document contents and the client address that issued them. Anything that displays, copies or exports them needs an explicit redaction and consent story.
• Platform support is uneven. Azure DocumentDB (vCore) rejects serverStatus, so anything derived from it is unavailable there and the surface has to degrade honestly rather than showing a sampling artifact dressed up as a rate.

Existing material

A working implementation is on feature/cluster-dashboard-poc and can be used as the starting point:

• src/webviews/documentdb/clusterDashboard/components/OperationsTab.tsx — the live table, history accordion, and kill flow
• src/webviews/documentdb/clusterDashboard/operationHistory.ts (+ tests) — occurrence identity and the observed-operation window
• clusterDashboardRouter.ts — getCurrentOperations, killOperation, clearOperationHistory
• src/documentdb/utils/getClusterHealth.ts — listCurrentOperations, killOperation, CURRENT_OP_SHARE_WINDOW_MS, and buildCommandPreview's redaction

Note that operationHistory.ts and listCurrentOperations are still in use: the dashboard's View Raw Diagnostics document reports current and observed operations even with the tab gone.

Open questions for the work item

• Is Operations a tab on the Cluster Dashboard, a separate view, or a tree surface?
• Does it poll continuously, or on demand? Continuous polling of a production cluster from a panel nobody is looking at is the failure mode to avoid.
• What is the minimum privilege set it should support, and what does it say when it has less?

Start with the prototype in src/webviews/documentdb/clusterDashboard/components/OperationsTab.tsx and operationHistory.ts, then trace getCurrentOperations, killOperation, and clearOperationHistory in clusterDashboardRouter.ts. Read getClusterHealth.ts and its tests to understand current-operation scope, redaction, history, and platform limitations. Done means the surface design, polling behavior, privilege messaging, kill status, transient history, and unsupported-platform behavior are explicitly resolved.