aspire update --channel staging can select daily package versions from a daily CLI

[maddymontaquila]

Summary

When running a daily Aspire CLI, aspire update --channel staging can resolve/update the app to daily package versions instead of staging package versions. This makes it hard to intentionally move an app from daily packages down to the staging channel.

Repro

1. Install or run a daily Aspire CLI build.
2. Use an Aspire app that is on daily package versions.
3. Run:

aspire update --channel staging

Expected

Passing --channel staging should constrain package resolution to the staging channel/packages. If a daily CLI cannot reliably know the staging feed/version to use, the command should fail clearly or require an explicit staging feed/version instead of selecting daily packages.

Actual

The update plan can propose daily package versions even though --channel staging was passed.

Brief RCA

UpdateCommand does honor the explicit option at the command-selection layer: it resolves --channel staging to the PackageChannel named staging from PackagingService.GetChannelsAsync().

The problem is that the staging channel produced by PackagingService is relative to the currently running CLI build/configuration rather than an independent staging target:

• CreateStagingChannel() calls GetStagingFeedUrl(...).
• For stable-quality staging, GetStagingFeedUrl(false) builds a darc feed URL from the current CLI assembly informational version/commit hash:
  darc-pub-microsoft-aspire-{currentCliCommitHash}.
• For prerelease/Both staging quality without an explicit feed override, the code intentionally uses the shared daily feed:
  https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet9/nuget/v3/index.json.

Then ProjectUpdater.GetLatestVersionOfPackageAsync() simply queries context.Channel.GetPackagesAsync(...), orders the returned packages by semantic version descending, and picks the highest version. So if the running daily CLI constructs a staging channel that points at the current daily build's darc feed or the shared daily feed, aspire update --channel staging still produces daily versions.

This is distinct from #16650: --channel is being read here, but the selected staging channel can resolve to the wrong feed/version for a daily-to-staging downgrade scenario.

Suggested fix

Make staging channel resolution deterministic for package updates and independent of the currently running daily CLI build. Possible approaches:

1. Require/provide an explicit staging feed/version for daily-to-staging downgrades.
2. Ensure daily CLI builds do not synthesize a staging channel from the daily build commit or shared daily feed unless that is explicitly requested.
3. Add validation/logging that displays the resolved feed/source and prevents --channel staging from selecting daily feed/package versions.

Add regression coverage where a daily CLI/channel configuration is present and aspire update --channel staging must not select daily package versions.

[mitchdenny]

I am moving this to 13.4, it shouldn't block the 13.3 release. however I have a fix in #16717 and once approved I will try to backport but its not absolutely mandatory that we take it since this is more of an internal testing a feature gap.