[VS Code] Avoid full workspace AppHost rediscovery on every AppHost save

## Summary

Saving an existing AppHost source file currently invalidates discovery for the entire workspace folder. `AppHostDiscoveryService` watches AppHost, project, and config files, but its cache and change event are workspace-scoped. `AppHostDataRepository` then marks workspace discovery pending and runs discovery across every workspace root again.

This means editing one AppHost can repeatedly put the Aspire pane back into discovery and redo repo-wide work. Streaming makes that work visible sooner, but I don't think we should be restarting the full search on every save.

## Expected behavior

Could we keep discovery running in the background and use the changed URI to invalidate only the affected AppHost? Saving an already-known AppHost should preserve the rest of the candidate set and tree state while that AppHost is re-evaluated.

Adding or removing an AppHost, changing a project/config file, or another structural change may still require a broader workspace scan.

## Acceptance criteria

- Saving a source file for a known AppHost does not clear all workspace discovery state or rerun full workspace discovery.
- Only the affected AppHost is re-evaluated and updated when the changed URI can be mapped to a known candidate.
- Other candidates and running AppHost UI remain stable while that refresh happens.
- Structural changes still trigger a full scan when necessary.
- Coverage uses a multi-AppHost workspace and verifies that saving one AppHost does not rediscover the others.

Related: #17941, #18175, #18054

cc @ellahathaway

Start by tracing AppHostDiscoveryService and AppHostDataRepository, focusing on how a changed URI invalidates discovery and how known candidates are refreshed. Use the multi-AppHost workspace scenario from the acceptance criteria to verify that saving one known AppHost preserves other candidates and running UI, while structural changes still trigger a full scan.

Written by the indexing model from the issue text.