Feature request: plugin UI contribution point in the VS Code/Cursor extension (webview/panel)

Problem

Claude Code plugins can ship skills, agents, hooks, MCP servers, LSP configs, and monitors — but have no way to contribute UI to the extension. The extension's webview providers are all first-party; a plugin's only user-facing surfaces are chat markdown and side effects. Verified against the documented plugin component set and by inspecting the extension bundle (all registerWebviewViewProvider calls are extension-owned).

Why it matters

Some plugin categories are fundamentally visual — dashboards, monitors, diff/report viewers. Today the only escape hatch is running a localhost web server from the plugin's MCP process and asking the user to open it in Simple Browser (workable, but outside the IDE's layout/lifecycle, with its own port/token management burden — I know because I ship exactly this: workflows-conductor, a live workflow-run dashboard that would be strictly better as a contributed panel).

Ask

A minimal, sandboxed UI contribution for plugins — any of:

1. webviews/ plugin component: an HTML entry the extension hosts in a webview view (CSP-sandboxed, message-passing to the plugin's MCP server), registered into the Views menu like first-party panels.
2. An "open URL in editor browser" capability invocable from plugin context (skill/tool result metadata), so localhost dashboards can at least open inside the IDE without keybinding workarounds.
3. Longer term: panel registration in the Desktop app's pane system (Views menu), which already demonstrates the UX model with the first-party tasks pane.

Context

The Desktop app's draggable tasks/subagent panes show Anthropic already has the interaction model; extending a constrained version to plugins would unlock an ecosystem of visual tools without each one reinventing localhost-server plumbing. Related: #72292 (the /workflows monitor gap that motivated ours).