Token audiences acquired lazily during deployment fail with short-lived federated credentials

### Is there an existing issue for this?

Searched `AADSTS700024` and "client assertion valid time range" — none found.

### Describe the bug

Aspire acquires Azure access tokens lazily, at the point each one is first needed. Entra issues tokens **per audience**, so a single deployment requests several, spread across the run:

| Audience | Requested by | When |
|---|---|---|
| `management.azure.com` | `AzureEnvironmentResource.cs:204` | early (provisioning) |
| `graph.windows.net` | `DefaultAzurePrincipalProvider.cs:29` | early (principal lookup) |
| `containerregistry.azure.net` | `AcrLoginService.cs:22` | **late** (image push) |

This breaks when deploying with a short-lived federated credential. `az login --service-principal --federated-token` caches an access token for the audience it was asked for and stores the assertion for later reuse — but the client-credentials flow issues **no refresh token**. So the first request for an audience that isn't already cached forces the stored assertion to be replayed, and if it has expired by then the deployment fails:

```
AADSTS700024: Client assertion is not within its valid time range.
Current time: 2026-08-21T04:07:03Z, assertion valid from 2026-08-21T03:49:11Z,
expiry time of assertion 2026-08-21T03:54:11Z.
```

GitHub Actions OIDC assertions live **5 minutes** and the lifetime is not configurable, so any deployment where more than 5 minutes elapse before the first image push hits this. Observed in [run 32443816572](https://github.com/microsoft/aspire/actions/runs/32443816572): provisioning ran **15m39s successfully** on the cached ARM token, then ACR login failed in **1.27s**.

ARM and Graph are equally exposed — they survive today only because they happen to be requested early. Any audience added later (Key Vault, storage data plane, AKS) inherits the same failure.

### Expected Behavior

A deployment shouldn't fail because an audience happened to be requested late in the run.

Neither obvious lever helps: the OIDC assertion lifetime is fixed by the identity provider, and federated client credentials cannot yield a refresh token ([Azure/azure-cli#28708](https://github.com/Azure/azure-cli/issues/28708)).

**Proposed fix:** have resources and compute environments declare the token audiences they require, so a deployment acquires them all immediately after authentication — while the credential is still valid — instead of discovering them lazily mid-deployment.

A pre-warm of `https://containerregistry.azure.net/.default` right after login unblocks CI in the meantime, but it hardcodes in the workflow a list that belongs in the product.

### Steps To Reproduce

1. `az login --service-principal --federated-token `
2. Do more than 5 minutes of ARM work — it succeeds on the cached ARM token
3. Push an image, requesting the ACR audience → `AADSTS700024`

### Exceptions (if any)

```
Login to ACR .azurecr.io failed: Azure CLI authentication failed due to an unknown error.
https://aka.ms/azsdk/net/identity/azclicredential/troubleshoot
ERROR: AADSTS700024: Client assertion is not within its valid time range.
Trace ID: 63ba9556-1fd2-48c7-bb24-87a5d7e21400
Correlation ID: 8400b8d8-b4c5-473f-80a2-85e98ebd37a6
```