E2E Deployment Test Failure: Aspire.Deployment.EndToEnd.Tests.AzureStorageDeploymentTests.DeployStarterWithSharedAzureStorageReferences

## Failing Test

`Aspire.Deployment.EndToEnd.Tests.AzureStorageDeploymentTests.DeployStarterWithSharedAzureStorageReferences`

## Symptom

The pipeline reports 25/28 steps succeeded but the `provision-webfrontend-containerapp` and `provision-apiservice-containerapp` steps fail with:

```
ContainerAppOperationError: Failed to provision revision for container app 'webfrontend'.
...
"infraacr3owrqblkgmtvy.azurecr.io/apiservice:aspire-deploy-20260530043910":
failed to resolve registry 'infraacr3owrqblkgmtvy.azurecr.io': lookup
```

```
Xunit.MicrosoftTestingPlatform.XunitException: System.InvalidOperationException :
Pipeline failed unexpectedly. Terminal output:
✅ 25/28 steps succeeded • ❌ 3 failed • Total time: 4m 59s
❌ provision-webfrontend-containerapp — Failed to provision webfrontend-containerapp
❌ provision-apiservice-containerapp — Failed to provision apiservice-containerapp
```

## Root Cause (suspected)

The Azure Container Apps control plane could not resolve the freshly created Azure Container Registry hostname (`infraacr3owrqblkgmtvy.azurecr.io`) when pulling the image. This looks like a transient DNS-propagation race between ACR creation and the first container-app revision pull rather than a code bug. The bicep, deploy ordering, and image tag all appear correct.

Possible mitigations to investigate:
- Add a small DNS-resolution wait/retry after ACR provisioning before issuing the first ACA revision deploy.
- Reuse a pre-existing ACR for the test (skipping the fresh-ACR DNS propagation window).
- Retry the failed `provision-*-containerapp` steps once on `failed to resolve registry`.

No high-confidence code fix has been identified yet; first occurrence observed.

## Affected Runs

- https://github.com/microsoft/aspire/actions/runs/26674380687 (2026-05-30)

> This issue was created automatically by a workflow analyzing Deployment E2E test failures on `main`.