azd up: RBAC propagation race causes 403 on first deploy when storage local auth is disabled

## Summary

When `azd up` provisions a Function App with a storage account that has local auth disabled (key-based access off), the subsequent `azd deploy` step fails with a 403 because the RBAC role assignment for the deploying user hasn't propagated yet.

## Repro

1. Use a template that disables local auth on the storage account (e.g., `simple-agent-functions-typescript`)
2. Run `azd up` on a fresh environment
3. Provisioning succeeds ✅
4. Deploy fails ❌ with:

```
InaccessibleStorageException: Failed to access storage account for deployment:
BlobUploadFailedException: Failed to upload blob to storage account:
Response status code does not indicate success: 403
(This request is not authorized to perform this operation using this permission.)
```

5. Waiting ~60s and running `azd deploy` again succeeds ✅

## Environment

- azd version: 1.24.2
- OS: macOS (Darwin)
- Template: `simple-agent-functions-typescript`
- Location: East US 2

## Expected Behavior

`azd up` should handle RBAC propagation delays gracefully — either by:
- Adding a brief wait/retry loop after provisioning before attempting blob upload
- Detecting the 403 as a transient RBAC propagation error and retrying automatically
- Or documenting the workaround (`azd deploy` after a short wait)

## Workaround

Wait ~60 seconds after the 403, then run `azd deploy` separately. The RBAC assignment will have propagated by then.

## Context

This is the correct security posture — disabling local auth on storage and using identity-based access. The issue is purely a timing/propagation gap between when the role assignment is created and when Azure Storage honors it.