Add current operations and kill operation support to Cluster Dashboard

Summary

Add a focused Current Operations experience to the Cluster Dashboard, including the ability to request that a running operation be killed.

This capability was removed from PR #823 so the inventory-focused dashboard could move forward faster. It should return as an independent feature with its own privilege handling, safety checks, polling behavior, and tests.

User experience

• Show active user operations reported by $currentOp when the connected server supports it.
• Present useful fields such as operation type, namespace, duration, client, and a safe command summary.
• Refresh while the operations view is visible and stop polling when the dashboard is hidden.
• Allow eligible operations to be killed from the dashboard.
• Require confirmation before sending killOp.
• Report that the kill request was accepted without claiming that the operation definitely stopped.
• Explain unsupported commands and insufficient privileges without breaking the rest of the dashboard.

Safety and privacy requirements

• Revalidate the selected operation immediately before sending killOp because operation identifiers can be reused.
• Preserve operation identifier types instead of assuming they are numeric.
• Exclude internal server work and the dashboard's own inspection requests from the user operation list.
• Redact credentials and authentication payloads before operation data reaches the webview, logs, telemetry, or diagnostics.
• Bound result size and prevent overlapping polls.
• Do not poll while the webview is hidden.
• Localize all user-facing text and keep confirmation and result messages accessible.

Acceptance criteria

• Supported clusters show a current operations list that refreshes without overlapping requests.
• Unsupported or privilege-limited clusters show an actionable unavailable state while the inventory remains usable.
• Eligible operations expose a kill action with a confirmation step.
• The implementation checks that the same operation is still active before sending the kill request.
• Kill results distinguish request acknowledgement, already completed operations, rejected requests, and errors.
• Sensitive command fields are redacted before crossing the extension host boundary.
• Polling stops when the dashboard is hidden and resumes with an immediate refresh when shown.
• Automated tests cover filtering, redaction, privilege degradation, recycled operation identifiers, polling lifecycle, and kill outcomes.

Out of scope

• Recently observed operation history across polling intervals.
• Activity charts, opcounters, and broader cluster health monitoring.
• Azure Monitor integration.

Related work

• PR #823
• Issue #61

Start by reading the existing Cluster Dashboard implementation and related work in PR #823, then trace how $currentOp and killOp would cross the extension-host and webview boundary. Define the filtering, redaction, privilege, polling, confirmation, and revalidation tests described in the acceptance criteria. Done means supported and unavailable states, safe kill outcomes, lifecycle-aware polling, and automated coverage for the listed cases.