`aspire update --self` should detect WinGet/.NET tool installs and redirect to proper update mechanism

[radical]

Description

aspire update --self currently performs an in-place binary replacement regardless of how the CLI was installed. This causes problems for WinGet and .NET tool installations:

1. WinGet install: Self-update replaces the binary inside the WinGet package directory (C:\...\WinGet\Packages\Microsoft.Aspire__DefaultSource\aspire.exe), leaves backup files (aspire.exe.old.*), and extra artifacts (Aspire.TypeSystem.xml, libsodium.dll). WinGet state becomes mismatched — winget list still shows the old version, and a future winget upgrade could conflict with the self-updated binary.

2. .NET tool install: Self-update replaces the 162KB .NET tool shim at ~/.dotnet/tools/aspire.exe with the full 132MB native binary. The .store directory is orphaned. dotnet tool list -g still shows the old version, and dotnet tool uninstall -g Aspire.Cli won't properly clean up.

Proposed Behavior

The CLI should detect how it was installed (based on its own executable path) and redirect to the appropriate update mechanism:

WinGet install (stable channel only)

• Detection: Executable path contains WinGet\Packages\Microsoft.Aspire
• Behavior: Instead of in-place update, display a message like:

  This installation is managed by WinGet. To update, run: winget upgrade Microsoft.Aspire

• Scope: Only for the stable channel, since WinGet only distributes stable versions. For non-stable channels, suggest installing via the release script (which takes PATH precedence over WinGet).

.NET tool install (all channels)

• Detection: Executable path is under ~/.dotnet/tools/
• Behavior: Instead of in-place update, display a message like:

  This installation is managed by the .NET tool system. To update, run: dotnet tool update -g Aspire.Cli

• Scope: All channels. For non-stable channels where the version may not be on NuGet, additionally suggest installing via the release script.

Script install (current behavior, unchanged)

• Detection: Executable path is ~/.aspire/bin/aspire.exe
• Behavior: Continue doing in-place self-update as today.

Context

Found during CLI acquisition playbook testing (scenarios W1 and W3):

• W1 (ISSUE-W1-03, W1-04): Self-update mutates WinGet-managed directory, leaves extra files, WinGet state mismatch
• W3 (ISSUE-W3-01): Self-update replaces .NET tool shim with native binary, orphans .store directory

Environment

• CLI Version: 13.2.0
• OS: Windows x64

[radical]

cc @davidfowl @DamianEdwards @mitchdenny

[KennethHoff]

There are some package managers out there that makes all packages read-only (Nix / nixpkgs) and it would be great if there could be a system in place that the packagers could use to ensure that self-updates aren't attempted (And then promptly fail due to lack of write permissions).

ASPIRE_ENABLE_SELF_UPDATE=false for example. This would disable the --self flag to the update command as well as the "Do you also want to update the CLI" prompt after using update. It could still tell the user when an update is available, but wouldn't prompt to actually update.

[DamianEdwards]

@KennethHoff this is a reasonable addition just as a standalone thing.

[DamianEdwards]

@radical I'm not sure we need this as the default experience in these scenarios seems fine from my testing.

[radical]

Closing in favor of #15932 .