Deployment pipeline should retry/detect readiness when a freshly-created ACR's hostname isn't yet DNS-resolvable

## Description

Deployment E2E tests intermittently fail immediately after a new Azure Container Registry (ACR) is provisioned, because the ACR's hostname is not yet resolvable via DNS. The `aspire deploy` pipeline does not wait for or retry on this condition — it treats the DNS failure as a terminal deployment error.

## Observed failure

Run: https://github.com/microsoft/aspire/actions/runs/32808769295/job/97685417403 (attempt 1, job `Deploy (Deployment.EndToEnd-TypeScriptJavaScriptHostingDeploymentTests)`)

```
ContainerAppOperationError: Failed to provision revision for container app 'api'. Error details: The following field(s) are either invalid or missing. Field
'template.containers.api.image' is invalid with details: 'Invalid value: "envacrlnmjylyulnjvo.azurecr.io/api:aspire-deploy-20260825043642": Get
"https://envacrlnmjylyulnjvo.azurecr.io/v2/": dial tcp: lookup envacrlnmjylyulnjvo.azurecr.io on 100.100.252.157:53: no such host';..
```

The ACR was created moments earlier in the same pipeline run (`provision-env-acr` step), and the very next step that references the registry's image (`provision-api-containerapp`) fails because the registry's DNS record hasn't propagated yet.

## Impact

This is a recurring, transient failure across the Deployment E2E suite (not limited to this one test) whenever a newly-created ACR is referenced immediately by a dependent resource (e.g. Container Apps). It produces false-negative CI signal and requires manual reruns.

## Suggested fix

Harden the `aspire deploy` pipeline/CLI logic so that steps depending on a freshly-provisioned ACR (or any freshly-created Azure resource referenced by hostname) detect and retry on this specific transient condition instead of failing immediately:
- After creating an ACR (or similar DNS-backed resource), poll/verify DNS resolution (or use a retry-with-backoff around the dependent deployment call) before proceeding to steps that reference its hostname.
- Distinguish this transient "not yet resolvable" class of error from genuine configuration errors so we don't mask real bugs, and cap retries with a reasonable timeout.

## Related

Filed as part of investigating the Deployment E2E Tests run for microsoft/aspire@80836ab (PR #19656). Not caused by that PR's changes — this is pre-existing, long-standing flakiness in the deployment pipeline's resource-readiness handling.