E2E Deployment Test Failure: Aspire.Deployment.EndToEnd.Tests.AcaCustomRegistryDeploymentTests.DeployStarterTemplateWithCustomRegistryToAzureContainerApps

## Failing Test

`Aspire.Deployment.EndToEnd.Tests.AcaCustomRegistryDeploymentTests.DeployStarterTemplateWithCustomRegistryToAzureContainerApps`

## Symptom

The test failed in the 2026-06-17 nightly Deployment E2E run during the `provision-webfrontend-containerapp` step:

```
04:48:12 (pipeline-execution) ✗ [ERR] Deployment failed: IdentityDoesNotExist: Managed Identity with resource ID
'{"error":{"code":"NotFound","message":"No managed service identities are associated with resource
'/subscriptions/***/resourcegroups/e2e-aca-custom-acr-27665952969-1/providers/Microsoft.App/containerApps/webfrontend'"}}'
does not exist.

5.36s ✗ provision-webfrontend-containerapp — Failed
37.98s ✓ provision-apiservice-containerapp
3m 52s ✓ provision-infra
20.92s ✓ provision-myacr
❌ Pipeline failed
```

`provision-infra`, `provision-myacr`, and `provision-apiservice-containerapp` all succeeded; only `provision-webfrontend-containerapp` failed, after only ~5 seconds. The ARM error is structurally odd: the message embeds a `NotFound` "no MSIs associated with resource" payload that is itself referring to the `webfrontend` container app being provisioned (which does not yet exist), surfaced as `IdentityDoesNotExist`. This pattern is consistent with an Azure-side timing/race condition where the identity reference is being resolved against the not-yet-created container app, rather than a misconfiguration in the generated Bicep.

## Affected Runs

- https://github.com/microsoft/aspire/actions/runs/27665952969 (2026-06-17) — first observed

This is the only occurrence in the last 9 nightly runs (2026-06-08 → 2026-06-17), so the failure currently looks transient.

## Root Cause

Unknown — likely a transient Azure ARM identity-resolution race in the East US deployment region during ACA provisioning rather than a regression in Aspire itself. Needs at least one more occurrence (and ideally the CLI log captured via #18254 once merged) to determine whether it is:

- A flaky Azure-side identity resolution timing issue.
- A reproducible ordering bug in the generated Bicep for `webfrontend-containerapp` when a custom registry is used.

## Next Steps

- Monitor subsequent nightly runs for repeat occurrences.
- Once #18254 is merged, the captured `~/.aspire/logs/cli_*.log` will surface the underlying ARM operation IDs to investigate further.
- If recurrence is confirmed, examine whether the generated Bicep for the `webfrontend` container app declares its user-assigned identity in a way that allows ARM to resolve it before the container app resource is created.

> This issue was created automatically by a workflow analyzing Deployment E2E test failures on `main`. No fix PR has been opened because the failure has been observed only once and the underlying ARM detail is not yet captured — there is no high-confidence fix to apply at this time.