Distinguish "project not loaded yet" from "no definition found" for F12

Summary

Split out of #220, which is closed by #50. #220's main ask — making Go to Definition non-blocking — is implemented. Its "Follow-on consideration" section is not, and would otherwise be lost when the issue auto-closes.

Problem

Now that GoToDefinitionAsync runs inside WithoutBlockingOnProjectLoadAsync, a definition request that arrives before the full project context is ready returns null immediately rather than queuing behind a cold MSBuild design-time build. That is the desired behavior.

The side effect is that null now means two different things:

1. Not ready yet. The project context is still loading, so no symbol has a source location. A retry a few seconds later will succeed.
2. Genuinely not found. The caret is not on a navigable target, or the target is metadata-only (an SDK/NuGet type such as Button, which is intended and documented).

VS Code renders both as "No definition found for 'X'", which implies the handler is missing in case 1. A user pressing F12 during the load window gets a message that says the thing they are looking for does not exist, when it does.

Possible directions

• Surface the loading state when a definition request arrives before the full context is ready, e.g. via the existing projectContextStatus notification the client already consumes for the status bar.
• Have the client show a transient message ("WinUI XAML project is still loading…") when F12 returns nothing and the context is known to be pre-Full.
• Consider whether the same treatment is warranted for hover, which has had this policy for longer and shares the ambiguity.

LSP has no first-class "ask again later" response for textDocument/definition, so this most likely needs to be handled client-side using status the client already has, rather than by changing the server's return value.

Notes

• Purely a UX-clarity issue. The non-blocking behavior from #220 is correct and should not be reverted.
• F12 on metadata-only SDK/NuGet types returning nothing is intended and documented in the README; any messaging should not imply those will eventually resolve.

Start by tracing the GoToDefinitionAsync flow and the existing projectContextStatus notification consumed by the client. Determine how the client can distinguish a pre-Full loading state from a genuine missing definition, while preserving non-blocking behavior and the documented metadata-only result; done means F12 no longer reports a loading project as permanently missing.