VS Code extension re-adds nonexistent AppHost omitted by `aspire ls`

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Describe the bug

The Aspire AppHosts view displays a nonexistent AppHost when `aspire.config.json` contains a stale or mistyped AppHost path.

For example, when the workspace contains the real project `aspire-apphost.csproj` but `aspire.config.json` references the nonexistent `aspire_apphost.csproj`, the extension displays both paths. The nonexistent entry is shown as buildable and exposes normal AppHost actions.

The CLI already handles configured AppHost candidates correctly. Verified with Aspire CLI `13.5.2`:

- Existing configured AppHosts are included once by `aspire ls`, including `--format json` and `--format json --stream`.
- Nonexistent configured AppHosts are omitted from candidate output.
- For a missing configured path, the CLI writes a warning to `stderr`, preserves valid discovered candidates on `stdout`, and exits successfully.

The extension then overrides that behavior in `AppHostDiscoveryService._includeConfiguredAppHostCandidate`: when the configured path does not match a CLI candidate, it appends the path with `status: 'buildable'` and `selected: true` without checking whether the file exists. This creates a phantom duplicate that the CLI deliberately excluded.

### Expected Behavior

The extension should follow the candidate set returned by `aspire ls` and must not re-add a configured path that the CLI omitted.

If a compatibility fallback remains necessary for older CLI versions, it should verify that the configured AppHost file exists before adding it as a candidate.

### Steps To Reproduce

1. Create a valid AppHost named `aspire-apphost.csproj`.
2. Add an `aspire.config.json` whose `appHost.path` references `aspire_apphost.csproj`, which does not exist.
3. Run `aspire ls` and observe that it warns about the missing configured path but lists only `aspire-apphost.csproj`.
4. Open or refresh the Aspire AppHosts view in VS Code.
5. Observe that the view displays both `aspire-apphost.csproj` and the nonexistent `aspire_apphost.csproj`.

### Exceptions (if any)

N/A

### Aspire doctor output

N/A — this is AppHost candidate reconciliation behavior rather than an environment or prerequisite failure.

### Anything else?

The JSON CLI behavior was also verified with stdout and stderr captured separately: candidate JSON remains exclusively on stdout, while the missing-config warning is emitted on stderr. The CLI exits with code `0` and returns the valid discovered AppHost.

Start at AppHostDiscoveryService._includeConfiguredAppHostCandidate and reproduce the mismatch with a stale appHost.path, then compare the extension's candidates with `aspire ls` output. Done means the extension does not re-add a configured path omitted by the CLI, while valid discovered AppHosts remain available; if the compatibility fallback is retained, verify the configured file exists first.

Written by the indexing model from the issue text.