[Feature]: Surface WinUI analyzer diagnostics during winapp run project builds

**Depends on:** project-mode support for `winapp run` (#633)

## Summary

Add WinUI analyzer support to the `winapp run` project-mode build pipeline so WinUI apps get the same diagnostics that the current helper workflow injects today.

This is the follow-on to project-mode run support: once `winapp run` can build a `.csproj`, it should also surface the WinUI-specific Roslyn analyzer warnings that help developers and agents catch common issues early. The long-term destination is to move that analyzer into the WinUI NuGet package itself.

## Problem

Today the analyzer is effectively hidden behind a helper script in the current workflow. That creates three problems:

- users only see the diagnostics if they happen to use the script
- the build logic is duplicated outside the CLI
- the analyzer path is not yet part of the canonical WinUI inner loop

As a result, `winapp run` can build and launch WinUI apps, but it does not yet provide the quality gate that the WinUI workflow depends on.

## Goals

- Surface WinUI analyzer diagnostics during `winapp run` project-mode builds
- Replace the current helper script as the primary build/run path for the WinUI dev workflow
- Keep analyzer output consistent for humans and agents
- Create a path to graduate the analyzer into the WinUI NuGet package
- Leave non-WinUI projects alone by default

## Non-goals

- Redesigning the analyzer rules themselves
- Expanding the analyzer to all .NET projects
- Solving build-log summarization or error filtering (tracked separately)
- Changing the project-mode launch behavior already covered by the run proposal

## Proposed behavior

### Build-time integration

- For WinUI project-mode builds, `winapp run` should automatically load the WinUI analyzer assets and targets before invoking the build/evaluation step.
- The analyzer should behave like a normal build-time diagnostic source:
- warnings appear in standard console output
- warnings remain visible in structured/JSON output
- the app behavior itself does not change

### Scope control

- Analyzer injection should be limited to WinUI / Windows App SDK projects.
- It should not add noise to unrelated .NET projects.
- The CLI should keep the same build output and launch semantics as project-mode run support.

### Migration path

1. `winapp run` becomes the canonical build/run entry point with analyzer support.
2. The current helper workflow can be simplified to call `winapp run` instead of owning its own build orchestration.
3. The analyzer can later move into the WinUI NuGet package so `dotnet build`, Visual Studio, and `winapp run` all surface the same diagnostics without wrapper-specific injection.

## Key implementation constraints

- Do not overwrite a user's existing `Directory.Build.props`
- Keep the injection path cleanup-safe if a temporary props file is still needed
- Support both MSBuild and `dotnet build` code paths
- Keep the analyzer IDs and guidance stable, because tooling and docs already depend on them

## Success criteria

- `winapp run MyApp.csproj` shows WinUI analyzer warnings on the same issues the current helper workflow catches
- The current workflow no longer needs custom build orchestration to get those diagnostics
- The analyzer experience is available on the canonical CLI path, not just in a helper script
- The transition to a packaged WinUI analyzer can happen later without changing the user-facing warnings

## Risks / watchouts

- Injecting the analyzer into the wrong projects could create noise
- Keeping the CLI, companion docs, and future NuGet package aligned could drift
- If analyzer assets remain wrapper-only for too long, users and agents will miss them outside the CLI path

## Why this matters

`winapp run` should be the source-to-run entry point. This proposal makes it the source-to-quality entry point too, so WinUI developers and agents get the same guardrails without depending on a separate script in another repo.