MAINT: Use DefaultAzureCredential directly for blob storage auth

[adrian-gavrila]

Description

Swaps the Azure user-delegation SAS flow in AzureBlobStorageIO and AzureBlobStorageTarget for direct DefaultAzureCredential data-plane auth. The explicit SAS-token path is untouched in both classes; only the no-token path changes.

This is a simplification, not an RBAC reduction. Storage Blob Data Contributor already includes the generateUserDelegationKey action, so the required built-in role is unchanged. What it drops is the per-call delegation-key round-trip and SAS minting, so the container client just authenticates with the caller's Entra identity directly. That removes the dependency on generateUserDelegationKey (relevant for minimal custom roles) and one Entra round-trip per client.

AzureBlobStorageIO now also closes the credential alongside its container client via a new _close_client_async helper.

Supersedes #1615 (closed, went stale vs main) and additionally covers AzureBlobStorageTarget, which answers the parity question raised on that PR.

Tests and Documentation

• Updated/added unit tests in tests/unit/models/test_storage_io.py and tests/unit/prompt_target/target/test_prompt_target_azure_blob_storage.py covering both auth paths and credential cleanup. All pass, pre-commit clean.
• Live-verified a real write -> path_exists -> is_file -> read round-trip through AzureBlobStorageIO against a storage account using DefaultAzureCredential.
• Known follow-up: AzureBlobStorageTarget has no client-close lifecycle today (its container client was never closed either), so the credential isn't closed. Tracked separately rather than adding a dispose pattern here.
• No doc changes, internal auth only.