Tracking: Complete the end-to-end Aspire experience in VS Code

## Goal

Make the Aspire extension for VS Code a complete default environment for the full Aspire developer loop: create or initialize an app, run it, debug it, test it, inspect it, manage resources, and deploy it across local, remote, C#, and polyglot workspaces.

The extension already has strong AppHost run/debug support, a live resource tree, AppHost CodeLens, dashboard integration, resource commands, Aspire CLI integration, and automatic Aspire MCP registration. The remaining work is primarily about making complete user journeys reliable, discoverable, and consistent.

This is an outcome-oriented tracker. It complements #19066, which tracks the operational queue of open extension issues and active pull requests.

## Exit criteria

### Setup and project creation

- ~~A new user can install or locate the Aspire CLI, create or initialize a project, and start the correct AppHost without environment-specific troubleshooting.~~
- Version or capability mismatches identify the installed components, the unsupported capability, and a concrete remediation.
- Enterprise package-source configuration works consistently for CLI and editor-driven template and package operations.
- ~~Project creation validates destination conflicts before generation begins.~~

### Workspace and AppHost identity

- ~~Single-root, multi-root, nested-repository, and linked-worktree workspaces resolve the intended AppHost consistently.~~
- ~~Ambiguous workspaces prompt for an AppHost instead of guessing or failing inside a non-interactive launch.~~
- ~~The selected AppHost is shared by F5, editor actions, the Aspire pane, lifecycle tools, and command-palette operations.~~

### Run and debug

- ~~Supported AppHost and resource debugger settings are honored.~~
- Users can attach supported debuggers to eligible resources in an already-running AppHost.
- ~~Missing debugger dependencies produce actionable install guidance rather than silently running without a debugger.~~
- Debug output is readable, correctly classified, and not duplicated.
- Per-language launch, attach, breakpoint, and teardown behavior has end-to-end coverage.

### Deployment and pipelines

- ~~Deploy, publish, and pipeline operations are discoverable from the AppHost in the Aspire pane.~~
- ~~Inputs use the Aspire interaction service, progress and output stay visible, cancellation is clean, and the extension delegates execution to the Aspire CLI.~~

### Remote and polyglot workflows

- Remote SSH, Dev Containers, WSL, and Codespaces have a defined and validated AppHost discovery, CLI, dashboard, debugger, and teardown model.
- ~~Java resources can participate in the supported resource-debugging workflow after the Java hosting integration is available.~~

### Reliability

- Blocking end-to-end coverage protects onboarding, AppHost discovery, launch, per-language debugging, resource actions, dashboard behavior, and teardown.
- Failures are classified with enough information to distinguish extension regressions, external debugger failures, and infrastructure failures.

## Scope

- Reuse the Aspire CLI, dashboard, interaction service, resource commands, and Aspire MCP server rather than duplicating those systems in the extension.
- Add editor-native entry points for common workflows while preserving terminal and `launch.json` configuration for advanced scenarios.
- Keep target-specific deployment configuration in the AppHost and Aspire deployment pipeline.
- Track generic editor or language-extension work here only when Aspire requires integration or lifecycle coordination.

## Related

- Editor-assistance language-model tools: #19460
- Worktree-aware AppHost lifecycle operations: #19357
- Open CLI diagnostic logs after failed commands: #19511
- Operational VS Code issue queue: #19066
- VS Code extension E2E health ledger: #19282
- Daily VS Code extension acquisition signature verification: #19475
- [Aspire VS Code extension documentation](https://aspire.dev/get-started/aspire-vscode-extension/)