…14434)

* Add Azure portal link for Resource Group in pipeline summary

When printing the Resource Group in the pipeline summary of `aspire deploy`,
include a clickable link to the Azure portal resource group page.

The link uses the format:
https://portal.azure.com/#@{tenantId}/resource/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/overview

Changes:
- AzureEnvironmentResource.AddToPipelineSummary: construct markdown link for resource group
- ConsoleActivityLogger.FormatPipelineSummaryKvp: convert markdown to Spectre markup for clickable links
- Add ConsoleActivityLoggerTests for the new markdown rendering behavior

Co-authored-by: eerhardt <8291187+eerhardt@users.noreply.github.com>

* Clean up the code

* Fix tests

* More test fixups

* Refactor code

* Update src/Aspire.Cli/Utils/MarkdownToSpectreConverter.cs

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

* Add test for color-enabled non-interactive rendering path

Co-authored-by: eerhardt <8291187+eerhardt@users.noreply.github.com>

* fix test

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: eerhardt <8291187+eerhardt@users.noreply.github.com>
Co-authored-by: Eric Erhardt <eric.erhardt@microsoft.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

…ondition (#14494)

* Fix tools/list infinite loop by removing notification from ListTools handler and adding change detection

The MCP server was entering an infinite tools/list loop because:
1. HandleListToolsAsync sent tools/list_changed notification after refreshing
2. The client responded with another tools/list request
3. This created a feedback loop: list → changed → list → changed

Fix:
- Remove SendToolsListChangedNotificationAsync from HandleListToolsAsync
  (the client already gets the fresh list since it requested it)
- Add change detection to RefreshResourceToolMapAsync (returns bool Changed)
- Only send tools/list_changed in HandleCallToolAsync when tools actually changed
- RefreshToolsTool always sends notification (explicit user action)

Co-authored-by: maddymontaquila <12660687+maddymontaquila@users.noreply.github.com>

* Use HashSet.SetEquals for more efficient tool change detection

Co-authored-by: maddymontaquila <12660687+maddymontaquila@users.noreply.github.com>

* Address review feedback: use no-allocation key comparison and bounded channel wait in test

- Replace HashSet.SetEquals with count check + iterate keys + ContainsKey to
  avoid allocation under lock in McpResourceToolRefreshService.
- Replace Task.Delay(200) in test with Channel.ReadAsync + CancellationTokenSource
  timeout for more deterministic negative assertion.

Co-authored-by: sebastienros <1165805+sebastienros@users.noreply.github.com>

* Check for both new and deleted tools in change detection

The previous change detection only iterated old→new keys, missing the
case where tools are swapped (same count but different keys). Now also
checks new→old to detect newly added tools.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Clean up comments in AgentMcpCommandTests

Removed comments about using TryRead for notifications.

* Fix resource name mapping

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: maddymontaquila <12660687+maddymontaquila@users.noreply.github.com>
Co-authored-by: sebastienros <1165805+sebastienros@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Co-authored-by: sebastienros <sebastienros@users.noreply.github.com>

* Fix permission denied error in Azure Pipelines

When we generate temporary dockerfiles, we are generating them directly under the TEMP directory. This can cause issues in some environments because docker build will walk all the files and folders next to the dockerfile as context to the build. For example, in AzDO pipelines, we can get an error like "ERROR: error from sender: lstat /tmp/.mount_azsec-KdAJKO: permission denied".

To fix this, we generate the Dockerfile in a subdirectory of TEMP, so it is the only file passed as context to docker build.

Fix #14523

* Add WithCompactResourceNaming() to fix storage name collisions

Fixes #14427. When Azure Container App environment names are long,
the uniqueString suffix gets truncated in storage account names,
causing naming collisions across deployments.

WithCompactResourceNaming() is an opt-in method that shortens storage
account and managed storage names to preserve the full 13-char
uniqueString while keeping names within Azure's length limits.

- Storage accounts: take('{prefix}sv{resourceToken}', 24)
- Managed storage: take('{name}-{volume}-{resourceToken}', 32)
- File shares: take('{name}-{volume}', 60)

Includes unit tests with snapshot verification and E2E deployment
tests covering both the fix and upgrade safety scenarios.

* Fix upgrade test: handle version prompt and backup/restore dev CLI

- Add version selection prompt handling for 'aspire add' (same as passing test)
- Back up dev CLI before GA install, restore after GA phase
- Update package to dev version after CLI restoration
- Set channel back to local after restore

* Remove the manifest from verify tests. It is not necessary.

* Remove unnecessary suppression

* Fix upgrade test: use 'aspire update' to actually upgrade project packages

The upgrade test was only swapping the CLI binary but the apphost.cs still
had #:package directives pointing to GA 13.1.0 packages. The deployment
logic comes from the NuGet packages, not the CLI, so the test was actually
redeploying with the old GA naming code both times.

Now uses 'aspire update --channel local' to update the #:package directives
in apphost.cs from GA → dev version, ensuring the dev naming code is
exercised during the second deployment.

* Fix upgrade test: handle 'Perform updates?' confirmation prompt

aspire update shows a y/n confirmation before applying package updates.
The test was waiting for 'Update successful' but the command was stuck
at the confirmation prompt.

* Fix upgrade test: handle NuGet.config directory prompt from aspire update

aspire update shows two prompts when switching channels:
1. 'Perform updates? [y/n]' - package confirmation
2. 'Which directory for NuGet.config file?' - NuGet config placement
Both need Enter to accept defaults.

* Fix upgrade test: use timed Enter presses for aspire update prompts

aspire update has multiple sequential prompts (confirm, NuGet.config dir,
NuGet.config apply, potential CLI self-update). Use Wait+Enter pattern
to accept all defaults without needing to track each prompt individually.

* Fix upgrade test: use explicit WaitUntil for each aspire update prompt

Timed Enter presses were unreliable — if prompts appeared at different
speeds, extra Enters would leak to the shell and corrupt subsequent
commands. Now explicitly waits for each of the 3 prompts:
1. 'Perform updates? [y/n]'
2. 'Which directory for NuGet.config file?'
3. 'Apply these changes to NuGet.config? [y/n]'

* Increase deploy WaitForSuccessPrompt timeout from 2 to 5 minutes

---------

Co-authored-by: Mitch Denny <mitch@mitchdeny.com>
Co-authored-by: Eric Erhardt <eric.erhardt@microsoft.com>

…ease-13.2-to-main