bug: AcrPull role not assigned to container app managed identity — image pull 401 on partial first deploy

Summary

On a first devclaw up where the ACA revision activation times out (Operation expired), the container app's system-assigned managed identity never gets the AcrPull role on ACR. Subsequent devclaw deploy calls push the image successfully but the container fails to start with a persistent 401.

Error seen in container system logs

Failed to construct registry secret for registry 'acrXXXXX.azurecr.io'
Error: ACR token exchange endpoint returned error status: 401

Steps to reproduce

1. Run devclaw up in a region/subscription where ACA revision activation times out on first run (e.g. southindia with a cold ACA environment, or any restricted corporate subscription)
2. Provision completes (ACR ✓, OpenAI ✓, Storage ✓, ACA env ✓) but revision fails with Operation expired
3. Run devclaw deploy — image is pushed to ACR but container immediately fails with ACR 401

Root cause

Bicep provisions ACR with adminUserEnabled: false (correct) and the container app is configured to pull via system-assigned managed identity — but the AcrPull role assignment on ACR for the container app's principalId is either missing or not yet propagated when the first revision activation is attempted. When the first azd up doesn't complete cleanly, this RBAC gap is never resolved.

Expected behaviour

Bicep should create an explicit AcrPull role assignment resource scoped to the ACR for the container app's managed identity, with correct dependsOn sequencing so the role is in place before the first revision is activated.

Manual workaround

PRINCIPAL_ID=$(az containerapp show -n <app> -g <rg> --query 'identity.principalId' -o tsv)
ACR_ID=$(az acr show -n <acr> -g <rg> --query 'id' -o tsv)
az role assignment create \
  --assignee-object-id $PRINCIPAL_ID \
  --assignee-principal-type ServicePrincipal \
  --role AcrPull \
  --scope $ACR_ID

Environment

• Region: southindia
• Restricted corporate subscription with Azure Policy assignments active
• azd version: latest, az CLI: latest

Reproduce the failure with devclaw up followed by devclaw deploy in the described Azure environment, then inspect the Bicep resources that provision ACR and the container app. Verify the managed identity, ACR scope, AcrPull role assignment, and dependency sequencing. Done means a partial first deployment followed by deploy starts the container without an ACR 401.