[VS Code] Expose editor-owned Aspire state and UI handoffs to agents

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Is your feature request related to a problem? Please describe the problem.

Aspire agents can start and stop an AppHost, but editor-owned state and UI operations are only available inside VS Code. An agent cannot safely determine whether an AppHost is already debugging, list extension-managed sessions, open the Dashboard or Aspire Output view, or explain the latest launch failure.

Without narrow editor-owned tools, agents would need to guess from stale process state, scrape output, or receive raw paths, URLs, logs, and exception details that should not cross the language-model boundary.

### Describe the solution you'd like

Add VS Code language-model tools for the editor-assistance operations that the Aspire CLI and MCP server do not own:

- Get bounded AppHost and exact-resource debug status.
- List active editor-managed Aspire debug sessions.
- Open the Dashboard for a validated AppHost. This does not confirm: it is a read-only handoff to a view the user already has a command and a tree-view button for, and the result never returns the Dashboard URL.
- Open the Aspire Output view after confirmation.
- Explain the latest launch failure using bounded categories and recommended action identifiers.

The tools should:

- Require a trusted workspace and resolve only AppHosts already discovered by the extension.
- Support multi-root workspaces without exposing absolute paths.
- Bind every resolved target to the exact AppHost identity and fail closed when the target changes or is ambiguous. Where a tool confirms, acceptance is bound to that identity too.
- Reuse the existing Dashboard launcher, Output channel, session state, and CLI-backed resource state.
- Avoid returning raw errors, logs, URLs, process IDs, command arguments, environment values, or resource properties.
- Include focused unit coverage and packaged Extension Host coverage for lifecycle, confirmation, privacy, and failure behavior, including that the Dashboard tool opens without prompting.

### Additional context

Implementation: #19414