[Feature]: Support C++ (.vcxproj) projects in `winapp run` with clear prerequisite guidance

Nobody has claimed this yet.

### Is your feature request related to a problem? Please describe.

`winapp run` project mode builds with `dotnet build` / `dotnet restore`, which have **no C++ project system** — the .NET SDK cannot restore or build a `.vcxproj`, and on a machine without Visual Studio there is no MSBuild VC toolchain present at all. This shows up in two ways:

1. **`.vcxproj` as the entry project** — `winapp run App.vcxproj` is currently rejected as a non-runnable input.
2. **`.vcxproj` as a build dependency** of an otherwise-managed WinUI / Windows App SDK app — the common "managed app + native helper / out-of-process COM server" shape. `winapp run` restores and builds only the managed side, so the native project isn't built and the app can fail at or after build.

Visual Studio handles both because it ships the C++ project system and the VC toolchain. `winapp run` aims for parity with a Visual Studio F5 run but currently can't reach it for any project graph that contains native C++ projects.

### Describe the solution you'd like

Give `winapp run` a **detect-and-delegate** path for C++ projects:

- **Detect the C++ toolchain** via `vswhere` (the "Desktop development with C++" workload plus the matching `MSBuild.exe`).
- **When present:** build C++ projects — the entry `.vcxproj`, or the `.vcxproj` dependencies of a managed app — by invoking the full `MSBuild.exe` (located via `vswhere`) instead of `dotnet build`, then continue the normal run / launch flow.
- **When absent:** **fail fast with a clear, actionable message** naming the exact prerequisites to install (and a link), rather than a raw `NETSDK1004` / `MSB####` error. Prerequisites to name:
- **Visual Studio** (any edition) **or Build Tools for Visual Studio** with the **"Desktop development with C++"** workload,
- the **Windows SDK**, and
- for WinUI / Windows App SDK C++ apps, the **C++/WinRT** and **Windows App SDK** components.
- **Non-goal:** winapp will **not** bundle the C++ toolchain (multi-GB, licensed) — detect-and-guide only.

**Acceptance criteria**
- `winapp run ` whose solution includes a `.vcxproj` dependency: with the Desktop C++ workload present, the native project builds (via `MSBuild.exe`) and the app runs; without it, a clear "install the Desktop development with C++ workload" message (not a raw SDK error).
- `winapp run ` directly: same detect-and-guide behavior.
- No regression for pure-managed project graphs (no `vswhere` / `MSBuild` shell-out when there is no `.vcxproj` in the graph).

### Additional context

- Part of a broader "additional project types" theme for `winapp run`. A related managed-side follow-up is support for Windows Application Packaging Projects (`.wapproj`). These can be scheduled independently.
- Can be picked up on its own, with no hard dependency on other work.

Start at the winapp run project-mode path and trace how project types currently select dotnet build and dotnet restore, including handling of App.vcxproj. Check how the project graph and launch flow are represented. Done means direct and dependency .vcxproj projects use the detected MSBuild path, missing prerequisites produce actionable guidance, and pure-managed graphs remain unchanged.

Written by the indexing model from the issue text.