Auto-register staging channel for staging CLI

[radical]

Description

Fixes #17121

A CLI binary built with the staging identity did not automatically register the staging package channel. That meant channel-aware commands such as aspire new could fall back to the implicit/default package source unless users also configured channel: staging or enabled the staging feature flag.

This change registers the staging package channel when the running CLI identity is staging, when project configuration requests channel: staging, or when a command explicitly requests the staging channel. Staging channel materialization now uses prerelease-capable package quality by default for identity/config/requested staging so staging builds can resolve staging packages correctly.

The change also preserves explicit channel precedence and makes mixed CLI routes safer:

• staging-created projects can persist channel: staging
• project-local staging pins are honored even when --apphost points outside the launch directory
• add/search/update/restore/new paths resolve staging through the shared packaging service
• explicit walk-back with aspire update --channel stable persists the stable channel for guest projects even when package versions are already current
• aspire config set -g overrideStagingFeed <url> is honored by later CLI invocations and flows into generated NuGet.config for staging C# template creation

User-facing usage

No new command syntax is required. Existing commands now honor the staging CLI identity automatically:

aspire new

When run from a staging CLI build, channel-pinning templates resolve from the registered staging channel and persist:

{
  "channel": "staging"
}

Users can still override the staging package feed globally:

aspire config set -g overrideStagingFeed https://example.com/nuget/v3/index.json

Users can still walk back explicitly:

aspire update --channel stable

Validation:

dotnet test --project tests/Aspire.Cli.Tests/Aspire.Cli.Tests.csproj --no-launch-profile -- --filter-class "*.ConfigCommandTests" --filter-not-trait "quarantined=true" --filter-not-trait "outerloop=true"
dotnet test --project tests/Aspire.Cli.Tests/Aspire.Cli.Tests.csproj --no-launch-profile -- --filter-method "*.NewCommand_CSharpEmptyTemplateUnderStagingIdentity_WritesStagingNuGetConfig" --filter-not-trait "quarantined=true" --filter-not-trait "outerloop=true"

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
      • No
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • Yes
      • No
  • No

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 17155

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 17155"

[Copilot]

Pull request overview

Fixes #17121 so a CLI built with AspireCliChannel=staging automatically registers the staging package channel, and ensures channel pins persist correctly when users explicitly walk back to stable.

Changes:

• PackagingService.GetChannelsAsync now also registers the staging channel when CliExecutionContext.IdentityChannel == "staging" or when configuration["channel"] == "staging", with quality defaulting to Both (while keeping the safe Stable fallback for invalid override values).
• GuestAppHostProject.UpdatePackagesAsync persists an explicit channel name even when no package updates are needed, so aspire update --channel stable from a staging-pinned project actually rewrites aspire.config.json#channel.
• KnownFeatures.IsStagingChannelEnabled remarks updated to remove the now-obsolete "by design, identity does not enable staging" wording.

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
src/Aspire.Cli/Packaging/PackagingService.cs	Adds identity-channel trigger for staging registration; threads default-quality into CreateStagingChannel/GetStagingQuality.
src/Aspire.Cli/KnownFeatures.cs	Updates the staging-channel remarks to reflect that callers now combine the helper with an identity check.
src/Aspire.Cli/Projects/GuestAppHostProject.cs	Persists explicit channel on the up-to-date path; reports UpdatesApplied=true when only the channel pin changes.
tests/Aspire.Cli.Tests/Packaging/PackagingServiceTests.cs	New tests for staging-identity registration and config-channel quality/feed defaults.
tests/Aspire.Cli.Tests/Packaging/NuGetConfigMergerTests.cs	New test for remapping Aspire.* from staging source to stable source.
tests/Aspire.Cli.Tests/Commands/NewCommandChannelResolutionTests.cs	Flips staging-identity expectation from "fall back to Implicit" to "resolve from staging".
tests/Aspire.Cli.Tests/Commands/NewCommandTemplateConfigPersistenceTests.cs	Updates staging-identity test to assert channel: staging pinning.
tests/Aspire.Cli.Tests/Commands/AddCommandTests.cs	Adds coverage for staging-pinned project under stable CLI and unpinned project under staging CLI.
tests/Aspire.Cli.Tests/Projects/GuestAppHostProjectTests.cs	Adds tests for persisting channel: stable on explicit walk-back, both with and without package changes.