[B4] aspire uninstall --self / --state-only

[radical]

Track B implementation. Depends on B0 (#33) + Q5 (#32).

Ship aspire uninstall --self and aspire uninstall --state-only per the recommendation in #32.

aspire uninstall --self [--keep-state | --purge] [--dry-run] [--yes]
aspire uninstall --state-only [--keep-config | --purge]

Branches by InstallRoute:

• Script / PrScript: removes binary + prunes PATH
• Winget / Homebrew / DotNetTool: refuses with route-specific instruction

--state-only is the missing piece for microsoft#15614 (W34/W35 cleanup) and is route-agnostic.

Code added

• src/Aspire.Cli/Commands/UninstallCommand.cs (new)
• Tests in Aspire.Cli.Tests/Commands/UninstallCommandTests.cs

Scenarios advanced

S6.1–S6.6.

---

Part of: #29

[radical]

Design implications from ordering-scenarios.md (#29):

The W34/W35 family (O4.1–O4.3) is the single highest-value fix in Track B and depends almost entirely on this issue:

• Uninstall must sweep the channel field of aspire.config.json if the route doing the uninstall is the route that wrote the channel. Without this, P-uninstall leaves S looking at PR's daily channel; S-uninstall leaves W looking at S's channel. This is the root cause of W34/W35 in bae142.
• Implies a channel-ownership record: aspire.config.json should carry channelSetBy: <install-id> (or a per-route channel section if Q3 lands "scoped"). Uninstall reads this and clears the channel only if it matches the uninstalling route.
• --state-only --purge (S4.3 / O4.7): preserves binary, wipes ~/.aspire/{hives,bundle,cache,sdks,installs/<self>} and clears channel unconditionally (since user opted into purge).
• --state-only (no purge): preserves binary AND state directories; only clears the route's sentinel and (if owned) the channel.
• O4.4–O4.6 (triple-uninstall in different orders): each step must leave surviving routes functional. Test all 3 permutations in CI smoke.
• Concurrent uninstall while CLI running (O5.5) — OQ-1: lean is warn-and-proceed with optional --force-while-running to suppress the warning. Tracked.
• Sentinel cleanup should be idempotent and atomic (write-temp + rename then delete).

Companion runbook scenarios: §4.1, §4.2-A/B/C, §4.3.
Runbook gist: https://gist.github.com/radical/86bce917075fd87e684be5c3aecb0c37