[Feature]: Explore composable templates and a guided `winapp new` experience

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

`winapp new` currently provides a simple two-step interactive flow: select one concrete template, then choose the project name. The official template catalog encodes several independent decisions into template short names (`winui`, `winui-mvvm`, `winui-navview`, `winui-tabview`), so the CLI cannot currently let a user choose an app shell and programming model independently.

This limits discoverability and prevents useful combinations such as NavigationView + MVVM or TabView + MVVM. It also makes adding Microsoft.UI.Reactor as an experimental MVU option awkward because Reactor is distributed through a separate template pack and has different framework and packaging defaults.

We own the relevant template experiences, so the design should include upstream template-pack changes rather than adding generated-code transformations or a compatibility matrix inside `winapp`.

This follows the initial `winapp new` work in #609 and should produce a full specification before implementation begins.

### Describe the solution you'd like

Explore and write a full spec for evolving `winapp new` into a capability-driven, guided project setup experience while keeping it a thin orchestration layer over owned `dotnet new` templates.

The initial design direction to evaluate is:

1. Select an artifact/template or app shell (blank, NavigationView, TabView, class library, unit test, or contextual item).
2. For app templates, conditionally select a programming model:
- XAML + code-behind
- XAML + CommunityToolkit.Mvvm
- Microsoft.UI.Reactor MVU (explicitly experimental)
3. Select a name.
4. Optionally expose additional customization later through progressive disclosure rather than making every choice mandatory.

The spec should treat template-pack support as an upstream dependency:

- **Windows App SDK template pack**
- Evaluate adding `--model ` to `winui`, `winui-navview`, and `winui-tabview`.
- Preserve existing defaults and keep `winui-mvvm` as a compatibility preset equivalent to a blank app with the MVVM model.
- Use conditional template sources/overlays rather than post-generation rewriting in `winapp`.
- Publish machine-readable metadata describing artifact kind, shell, supported models, requirements, and maturity.

- **Microsoft.UI.Reactor template pack**
- Evaluate adding `--shell ` to `reactorapp`.
- Keep Reactor as a separate experimental provider rather than embedding Reactor sources into the Windows App SDK template pack.
- Define how its .NET 10 requirement and unpackaged default are surfaced in the guided experience.

- **winapp CLI**
- Discover available choices from installed template metadata and only prompt when multiple valid choices exist.
- Preserve `--template` as the concrete-template escape hatch.
- Preserve the current behavior of `--use-defaults`, non-interactive fallback, `--json`, exit codes, telemetry, and npm API generation.
- Fail clearly when a requested capability requires a newer template-pack version.

The spec should compare parameterized templates against adding concrete variants, define the preferred ownership boundary, and explicitly avoid having `winapp` modify arbitrary generated source files.

### Additional context

Template Studio is useful precedent for its taxonomy—project type, programming model, pages, features, services, and tests—and for dependency-aware composition. We should borrow that taxonomy without recreating its full composition engine inside the CLI.

Questions the spec should resolve:

- What does MVVM support mean for NavigationView and TabView templates: basic page ViewModels matching the existing `winui-mvvm` template, or a broader DI/navigation-service architecture?
- Should shell and model be parameters on existing templates or represented by additional concrete templates?
- What metadata contract lets `winapp` discover shells, models, maturity, requirements, and incompatibilities without hardcoding template names?
- How do source changes shared between the dotnet template pack and the Visual Studio VSIX remain compatible?
- What are the graduation criteria for exposing Reactor beyond an experimental choice?
- Should later pages/features be project-template flags, item/feature templates, or a future post-generation command?
- What telemetry or user research should inform the initial choices and defaults?

Expected spec deliverables:

- Interactive UX and progressive-disclosure flow
- Complete non-interactive command/JSON/npm surface
- Template capability and metadata contract
- WindowsAppSDK and Reactor template-pack changes
- Compatibility and migration behavior for existing template short names
- Cross-repository ownership and release sequencing
- Supported-combination and build validation matrix
- Phased scope for shells/models first and pages/features later

Initial validation should generate and build every supported shell/model combination, verify legacy template invocations remain unchanged, and ensure template-only overlay files never leak into generated projects.