[Feature]: Add Native AOT publish and run support #816

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

winapp run <csproj> currently builds with dotnet build, resolves TargetDir, and launches that output. Modern .NET Native AOT compilation happens during dotnet publish, so even projects with PublishAot=true can be launched from a JIT build layout containing CoreCLR/JIT files rather than from the native published executable.

Callers must currently guess publish output paths and reimplement packaged-app staging, Windows App Runtime dependency handling, loose registration, and AUMID activation. Packaged Native AOT apps require package identity and cannot be launched directly, while unpackaged Native AOT apps must launch directly without packaged-only options. Automation also lacks enforceable proof that the launched process came from the selected publish and loaded no CoreCLR/JIT modules.

Describe the solution you'd like

Add first-class project publish and Native AOT verification to winapp run:

winapp run App.csproj `
  --publish `
  --verify-native-aot `
  -c Release `
  -r win-x64 `
  --detach

New project-mode options:

• --publish: run dotnet publish, evaluate the exact absolute PublishDir using the same configuration, RID, platform, framework, publish profile, solution properties, and repeatable -p values, then launch that artifact.
• --verify-native-aot: imply --publish; require evaluated PublishAot=true and a concrete Windows RID; verify the static payload, reject .NET single-file JIT bundles, launch provenance, startup survival, loaded modules, and packaged registration provenance.
• --dry-run: evaluate project settings and native toolchain readiness without restoring, publishing, registering, or launching. Return Ready: null with an exact restore command when readiness is indeterminate.

Preserve existing behavior by default and preserve .NET CLI semantics for --no-build: skip dotnet build in build mode, but pass --no-build to dotnet publish in publish mode.

Use operation-aware project preparation (Build or Publish), reusable Windows native toolchain discovery, and architecture-aware support for win-x64 and win-arm64. Preflight must locate vswhere.exe, validate the target-specific Visual Studio C++ component/linker and Windows SDK, and inject the required child-process environment without installing workloads.

For packaged publishes, reuse the existing loose-layout staging and registration behavior with the evaluated generated manifest. For unpackaged publishes, launch the exact PublishDir executable directly and reject packaged-only options. Cross-worktree identity isolation remains outside this feature.

Extend default, verbose, and JSON output with operation, readiness, source artifact, publish/staging/process paths, package identity, PID, window state, toolchain versions, and layered verification results while retaining the existing top-level AUMID, ProcessId, and Error contract.

Additional context

Acceptance criteria:

• winapp run App.csproj --publish launches the artifact produced by that invocation's evaluated PublishDir.
• winapp run App.csproj --verify-native-aot succeeds for known-good packaged and unpackaged Native AOT fixtures and fails for JIT/self-contained single-file substitutes.
• Verification guarantees the process survives the internal readiness window, comes from the selected publish/staging layout, and loads no CoreCLR/JIT modules.
• Packaged registration install location matches the unique development staging directory.
• Missing C++ Build Tools fail before publish with actionable Visual Studio Installer guidance.
• Default and verbose output provide the same material facts and remediation as JSON.
• Existing winapp run App.csproj and folder-mode behavior remain unchanged.
• x64 packaged and unpackaged runtime acceptance passes on x64; the same portable acceptance workflow can be run on a Windows ARM64 device for ARM64 validation.

Non-goals: changing dotnet build semantics, making Native AOT the default inner loop, installing Visual Studio workloads automatically, redesigning general staging ownership/lifetime or package concurrency, and replacing Store/MSIX release packaging.