XAML server: in-flight project loads can cache a pre-invalidation graph

Found while reviewing PR #50 (originally review finding M4).

XamlProjectResolver.Invalidate (server/src/WinUiXaml.Workspace/XamlProjectResolver.cs:204-239) evicts:

• the cache entry keyed by the changed project, and
• completed entries whose Result.ContainsProject(key) is true.

The gap: a load for a different root that is still in flight cannot be tested with ContainsProject, because the project graph does not exist until the load completes. If that pending load turns out to reference the invalidated project, it is cached afterwards with a pre-invalidation graph and is never evicted. In practice this can leave IntelliSense stale until the next edit to that project.

An attempted fix — adding || !pair.Value.IsCompleted to the predicate — was reverted, because it is not scoped to key and therefore evicts every in-flight load across all roots. That caused worse problems: DisposeWhenComplete would dispose a RoslynProjectWorkspace that other callers were already awaiting in ResolveAsync, plus duplicated MSBuild design-time loads, plus a possible no-progress loop where saves during a cold load repeatedly restart it.

Suggested work:

• Record each pending load's candidate project set (e.g. the project paths known at load kickoff) so pending entries can be tested against key without waiting.
• Alternatively, re-check ContainsProject on completion and self-evict, rather than eviction at invalidate time.
• Either way, do not dispose a cached workspace task that active ResolveAsync callers may still be awaiting — that hazard exists today even for the same-key path.