winapp new --template-version latest downgrades a newer installed template pack, silently dropping the Reactor templates

Nobody has claimed this yet.

## Summary

`winapp new` treats the nuget.org pack as "latest" without comparing versions, so it will **downgrade** a newer locally-installed `Microsoft.WindowsAppSDK.WinUI.CSharp.Templates` pack. When the newer pack is an ADO build that contains the Reactor templates and the nuget.org one does not, the Reactor templates **silently disappear** — `winapp new --list` then reports a smaller list with no error.

A secondary symptom: while two versions of the pack are installed simultaneously, `winapp new --list` fails outright with a confusing parse error.

## Environment

- `winapp` **0.6.3-prerelease.38** (run `35028376020`, `8b9121f6`)
- Newer pack: `Microsoft.WindowsAppSDK.WinUI.CSharp.Templates` **0.0.7-alpha-2026-0911-2329-pr0**
(ADO `WinAppSDK-BuildDotnetTemplate`, definition 186691, build 157345005 — contains the Reactor templates from WindowsAppSDK #6620 + #6728)
- Older pack: **0.0.6-alpha** (nuget.org — no Reactor templates)

## Repro

**1. Install the newer ADO pack and confirm it is healthy**

```powershell
dotnet new install Microsoft.WindowsAppSDK.WinUI.CSharp.Templates.0.0.7-alpha-2026-0911-2329-pr0.nupkg
winapp new --list
```

```
i Available WinUI templates (pack 0.0.7-alpha-2026-0911-2329-pr0):
| Reactor Blank App (Experimental) | reactor | project |
| Reactor MVU App (Experimental) | reactor-mvu | project |
| Reactor NavigationView App (Experimental) | reactor-navview | project |
| Reactor TabView App (Experimental) | reactor-tabview | project |
| WinUI Blank App | winui | project |
| WinUI MVVM App | winui-mvvm | project |
...
```

**2. Ask for "latest" — which is also the default path when the pack is judged stale**

```powershell
winapp new --template-version latest --list
```

```
i Installing WinUI template pack Microsoft.WindowsAppSDK.WinUI.CSharp.Templates...
i Available WinUI templates (pack 0.0.6-alpha):
| WinUI Blank App | winui | project |
| WinUI Class Library | winui-lib | project |
| WinUI MVVM App | winui-mvvm | project |
| WinUI NavigationView App | winui-navview | project |
| WinUI TabView App | winui-tabview | project |
```

Exit code **0**. No warning.

**3. The Reactor templates are gone**

```powershell
dotnet new list | Select-String reactor # -> no matches
dotnet new uninstall | Select-String "WinUI.CSharp.Templates" -Context 0,1
# Microsoft.WindowsAppSDK.WinUI.CSharp.Templates
# Version: 0.0.6-alpha
```

`winapp new --template reactor` now fails, and the only clue is a shorter `--list`.

## Why this is a downgrade, not a no-op

`0.0.7-alpha-2026-0911-2329-pr0` is strictly newer than `0.0.6-alpha` by semver — the patch component differs (7 > 6), so the prerelease labels are never compared:

```powershell
[System.Management.Automation.SemanticVersion]"0.0.7-alpha-2026-0911-2329-pr0" -gt
[System.Management.Automation.SemanticVersion]"0.0.6-alpha"
# True
```

## Secondary symptom: two versions installed breaks `--list` entirely

While both packs are installed, `winapp new --list` fails:

```
x Could not enumerate WinUI templates from the installed pack
'Microsoft.WindowsAppSDK.WinUI.CSharp.Templates': Could not verify which templates
'Microsoft.WindowsAppSDK.WinUI.CSharp.Templates' owns: no template list for it in
'dotnet new uninstall' output. Re-run with --verbose to see that output.
```

Root cause: both versions declare the same template identities, so `dotnet new uninstall` prints conflict blocks instead of a per-pack template list:

```
The following templates use the same identity 'Microsoft.WindowsAppSDK.WinUI.CSharp.BlankApp':
- 'WinUI Blank App' from 'Microsoft.WindowsAppSDK.WinUI.CSharp.Templates@0.0.6-alpha'
- 'WinUI Blank App' from 'Microsoft.WindowsAppSDK.WinUI.CSharp.Templates@0.0.7-alpha-2026-0911-2329-pr0'
The template from 'WinUI Blank App' will be used. To resolve this conflict, uninstall the conflicting template packages.
```

The parser looks for a template list under the pack name and finds a conflict block instead. Workaround is `dotnet new uninstall ` (removes *all* versions) then install exactly one.

## Suggested behaviour

1. **Compare versions before replacing.** If the installed pack is newer than the candidate, keep it — or at minimum warn loudly and require `--force`/an explicit `--template-version` to downgrade.
2. **Never silently reduce the template set.** Dropping templates that were previously available should be an explicit, surfaced action rather than a quieter `--list`.
3. **Handle the multi-version conflict.** Either uninstall all versions before installing, or parse the conflict block so `--list` degrades gracefully instead of hard-failing.

## Impact

Found while benchmarking WinUI/XAML against Microsoft.UI.Reactor. The official Reactor templates only exist in the ADO build today, so any `winapp new` invocation that resolves "latest" silently reverts the toolchain to a pack without them — and the failure presents as "the Reactor templates don't exist" rather than "your template pack was downgraded".

Not urgent once nuget.org carries a pack containing the Reactor templates, but the downgrade-without-warning behaviour is worth fixing on its own.

Reproduce with the reported `winapp new --template-version latest --list` and multi-version installation steps. Start by tracing the template-pack version-selection path and the parser for `dotnet new uninstall` output. Done means a newer installed pack is not silently downgraded, and multiple installed versions no longer make `winapp new --list` fail without a clear result.

Written by the indexing model from the issue text.