Add E2E test coverage for per-language debugger launch flows in the VS Code extension

The VS Code extension has no end-to-end coverage for launching a debug session against an individual resource in any language. Every per-language debug adapter is verified only by unit tests that assert on the launch configuration object, so nothing exercises the path where VS Code actually attaches a debugger to a running resource.

## Current state

`extension/src/debugger/languages/` has 11 adapters:

```
azureFunctions.ts bun.ts dotnet.ts maui.ts python.ts
browser.ts cli.ts go.ts node.ts rust.ts
javascriptRuntime.ts
```

Seven of those have unit tests (`bunDebugger.test.ts`, `dotnetDebugger.test.ts`, `goDebugger.test.ts`, `mauiDebugger.test.ts`, `nodeDebugger.test.ts`, `pythonDebugger.test.ts`, `rustDebugger.test.ts`). `azureFunctions`, `browser`, `cli` and `javascriptRuntime` have none.

The `extension/src/test-e2e/` suite is entirely extension-shell scope — AppHost discovery, the tree view, command palette routing, settings files, the package contribution surface, and debugging *the AppHost itself* through to the dashboard. The only place a language debugger appears is `packageSurface.e2e.test.ts` → *"routes editor and CodeLens debug commands to the expected Aspire launch types"*, which asserts that a debug type is registered, not that a session starts.

## Why this matters

The unit tests assert on the shape of the launch configuration we hand to VS Code. They cannot catch the failures that actually reach users:

- the configured debug extension is missing, disabled, or has changed its configuration schema
- the launch configuration is well-formed but rejected by the debug adapter at runtime
- the resource is not yet listening / the executable is not yet on disk when we attach
- the debug session starts but never binds to the process, or binds to the wrong one
- session teardown leaves the debuggee or its child processes running

These are all reasons a debug session silently does nothing, and today none of them would fail a build.

## Suggested scope

Start with one representative language end to end — run an AppHost with a single resource, start a debug session against it, assert the session reaches a stopped-on-breakpoint state, then stop and assert the process tree is gone. Once that harness exists, adding further languages should be mostly fixture work.

The main open question is infrastructure: a real per-language debug E2E needs the language toolchain *and* its VS Code debug extension present in the E2E runner (cargo + CodeLLDB, delve + the Go extension, debugpy + the Python extension, and so on). That is a decision for the suite as a whole rather than something to bolt on per language, which is why this is filed separately rather than blocking any one integration.

## Context

Raised while reviewing the Rust hosting integration in #18906. Rust is at parity with the existing languages here (unit test, no E2E), so this is not specific to that PR.

Start in extension/src/test-e2e/ and packageSurface.e2e.test.ts, then compare the adapters under extension/src/debugger/languages/ with their existing unit tests. Choose one representative language and verify the E2E runner has its toolchain and VS Code debug extension. Done means a resource reaches a stopped-on-breakpoint state and teardown leaves no debuggee or child processes running.

Written by the indexing model from the issue text.