aspire deploy hangs indefinitely (0% CPU, no error) after all Azure resources are successfully provisioned

### Is there an existing issue for this?

- [x] I have searched the existing issues (closest related: #16608, which is a similar "0% CPU / no error" deadlock class but for `PublishAsHostedAgent`, already fixed)

### Describe the bug

`aspire deploy` never terminates (no error, no further console/log output) after **all** Azure resources have been successfully provisioned. The process (both `aspire.exe` and the AppHost `dotnet.exe` process) stays alive indefinitely with ~0% CPU usage.

Verified independently via Azure CLI that **every** ARM deployment for the run (identity, storage, sql, search, foundry account, foundry project, container apps environment, all container apps and container app jobs) reached `Succeeded`, and all Container Apps show `provisioningState: Succeeded` / `runningStatus: Running`. So this is not an Azure-side provisioning issue — the hang happens purely inside the CLI/AppHost process after provisioning work is already done.

The internal CLI log file (`~/.aspire/logs/cli__.log`) stops writing entirely right after the log line for the **last** container app deployment completion — no further `[AppHost]` log lines appear for 25+ minutes (still hanging when I stopped observing it).

Last lines of the log before it goes silent:

```
[2026-09-03 08:35:56.938] [INFO] [AppHost] dbug: Aspire.Hosting.Azure.Provisioning.BicepProvisioner[0]
[2026-09-03 08:35:56.938] [INFO] [AppHost] Deployment of resource api-containerapp to resource group completed in 00:00:34.7480866
[2026-09-03 08:35:56.938] [INFO] [AppHost] info: Aspire.Hosting.Pipelines.Internal.FileDeploymentStateManager[0]
[2026-09-03 08:35:56.938] [INFO] [AppHost] Skipping deployment state save due to --clear-cache flag
[2026-09-03 08:35:56.998] [INFO] [AppHost] dbug: Aspire.Hosting.Azure.Provisioning.BicepProvisioner[0]
[2026-09-03 08:35:56.998] [INFO] [AppHost] Deployment of resource sp-sync-job-containerapp to resource group completed in 00:00:34.8875467
[2026-09-03 08:35:56.998] [INFO] [AppHost] info: Aspire.Hosting.Pipelines.Internal.FileDeploymentStateManager[0]
[2026-09-03 08:35:56.998] [INFO] [AppHost] Skipping deployment state save due to --clear-cache flag
[2026-09-03 08:35:57.227] [INFO] [AppHost] dbug: Aspire.Hosting.Azure.Provisioning.BicepProvisioner[0]
[2026-09-03 08:35:57.227] [INFO] [AppHost] Deployment of resource bot-api-containerapp to resource group completed in 00:00:35.0535139
[2026-09-03 08:35:57.227] [INFO] [AppHost] info: Aspire.Hosting.Pipelines.Internal.FileDeploymentStateManager[0]
[2026-09-03 08:35:57.227] [INFO] [AppHost] Skipping deployment state save due to --clear-cache flag
[2026-09-03 08:35:57.361] [INFO] [AppHost] dbug: Aspire.Hosting.Azure.Provisioning.BicepProvisioner[0]
[2026-09-03 08:35:57.361] [INFO] [AppHost] Deployment of resource wiki-sync-job-containerapp to resource group completed in 00:00:35.0908109
[2026-09-03 08:35:57.361] [INFO] [AppHost] info: Aspire.Hosting.Pipelines.Internal.FileDeploymentStateManager[0]
[2026-09-03 08:35:57.361] [INFO] [AppHost] Skipping deployment state save due to --clear-cache flag
```
(Nothing further is ever logged.)

`aspire deploy --list-steps` shows the steps that should run right after this point, which never appear to complete (no corresponding log entries after the timestamp above):

```
57. compute-endpoints-foundryProject
└─ Depends on: provision-azure-bicep-resources

58. print-api-summary
├─ Depends on: provision-api-containerapp
└─ Tags: print-summary

59. print-bot-api-summary
├─ Depends on: provision-bot-api-containerapp
└─ Tags: print-summary

60. print-dashboard-url-cae
├─ Depends on: provision-azure-bicep-resources, provision-cae
└─ Tags: print-summary

61. print-endpoint-summary
├─ Depends on: provision-endpoint-containerapp
└─ Tags: print-summary

... (similar print-*-summary steps for each container app job)

67. deploy
└─ Depends on: validate-azure-login, create-provisioning-context, provision-azure-bicep-resources,
compute-endpoints-foundryProject, print-dashboard-url-cae, print-api-summary,
print-bot-api-summary, print-endpoint-summary, print-ingest-fc-job-summary,
print-ingest-fd-job-summary, print-wiki-sync-job-summary, print-gh-sync-job-summary,
print-sp-sync-job-summary, build-api, build-bot-api, build-endpoint,
build-ingest-fc-job, build-ingest-fd-job, build-wiki-sync-job, build-gh-sync-job,
build-sp-sync-job
```

Process inspection while hung (25+ minutes after the last log line):

```
Id ProcessName Path CPU (total) RunningMin
19480 aspire C:\Users\\.aspire\bin\aspire.exe ~7.2 s 32.6 min
38352 dotnet C:\Program Files\dotnet\dotnet.exe (AppHost) ~5.1 s 32.2 min
```

Both processes report `Responding = True` (not OS-level hung), but CPU usage barely increases over many minutes — consistent with an async `Task` that is awaited but never completes (a "silent" deadlock), similar in shape to the dump analysis in #16608 (a `Task` awaited via an `EndpointReference`/output resolution that is never satisfied when the resource was provisioned purely through the deploy/ARM path rather than the local run/orchestrator path). One `Established` outbound HTTPS connection to an Azure (AS8075) IP remains open on the AppHost process the entire time, suggesting it may be waiting on a response, or holding an idle connection while blocked on an in-memory `Task` that will never complete.

The AppHost does **not** use `PublishAsHostedAgent`/`AzureHostedAgentResource` at all, so this does not look like exactly the same code path as #16608 — it appears the same *class* of bug (a step awaiting an in-memory endpoint/output value that's only ever populated in run/local mode, not in deploy mode) may also affect one of the later "print summary" / "compute endpoints" steps for plain Azure Container Apps and/or the Microsoft Foundry project resource.

### Expected Behavior

`aspire deploy` should either:
- Complete normally once all underlying Azure resources are provisioned (resolving final summary/endpoint values from the deployment outputs rather than from an in-memory value that requires a local run), or
- Fail fast / time out with a clear error instead of hanging silently forever with 0% CPU.

### Steps To Reproduce

1. AppHost with several Aspire-managed Azure Container Apps (web APIs + several `ContainerAppJob`/scheduled jobs), an Azure SQL database, Azure Storage, an Azure AI Search resource, and a Microsoft Foundry account + `AddProject(...)` (Foundry Project) resource, all sharing a single user-assigned managed identity (`ClearDefaultRoleAssignments()` + explicit `WithRoleAssignments(...)` per resource).
2. Run `aspire deploy` against a resource group and let it run to completion (this always eventually provisions **all** resources successfully in Azure).
3. Observe that the CLI never prints the final "deploy succeeded" / endpoint summary output and never exits, even though every Azure resource is fully provisioned (verified via `az deployment group list` / `az containerapp list`).
4. Confirm the hang via `~/.aspire/logs/cli_.log` — logging stops abruptly right after the last container app / container app job deployment log line.

### Exceptions (if any)

_No response — this is a silent hang, no exception is thrown or logged._

### Anything else?

- Aspire CLI: `13.5.3+b5f143315ffb6968ea939a9978797a5b20e4c688` (latest at time of filing)
- .NET SDK: `10.0.400`
- OS: Windows 10.0.26200.0 (Windows 11 24H2-class build)
- Packages involved: `Aspire.Hosting.Azure.AppContainers`, `Aspire.Hosting.Foundry`, `Aspire.Hosting.Azure.Sql`, `Aspire.Hosting.Azure.Storage`, `Aspire.Hosting.Azure.Search`
- Target: Azure Container Apps + Microsoft Foundry project
- Workaround found: since all Azure resources are already fully and correctly provisioned by the time the hang occurs, it is safe to `Ctrl+C` the stuck `aspire deploy` process — no in-progress Azure work is lost, and resource state can be independently confirmed via `az deployment group list --resource-group ` and `az containerapp list --resource-group `.

### Aspire doctor output

_Not collected (process was mid-deploy at the time of investigation)._

Start with the `aspire deploy` entry point, the `--list-steps` output, and the CLI log entries ending after the final container app deployment. Trace the post-provisioning steps, especially endpoint computation and print-summary steps, to identify the await that never completes. Done means deploy exits successfully with its summaries, or reports a clear timeout or error instead of hanging.

Written by the indexing model from the issue text.