Create migration guides for all official Azure SDK for Rust crates

## Create migration guides for all official Azure SDK for Rust crates

We need migration guides to help users transition from unofficial/community crates and older SDK versions to the official Azure SDK for Rust libraries.

### Background

The Azure SDK for Rust has gone through three eras:

1. **Community era (2017–2019):** MindFlavor's `azure_sdk_*` crates ([MindFlavor/AzureSDKForRust](https://github.com/MindFlavor/AzureSDKForRust))
2. **Experimental era (2022–2024):** Azure-published `azure_*` crates, v0.1–0.21 (not stable)
3. **Official/GA era (2025+):** Current rewrite with stable API design, new crate names for several services

Many Rust developers are using crates from eras 1 or 2, or community alternatives like [`azeventhubs`](https://crates.io/crates/azeventhubs)/[`azservicebus`](https://crates.io/crates/azservicebus). Each migration guide should cover:

- What the predecessor crate was and its relationship to the official crate
- Key API differences and breaking changes
- Step-by-step migration instructions with code examples
- Common pitfalls and FAQ

### Sub-Issues

- [ ] #4230 — Migration guide: `azure_core` (from azure_core ≤0.21.0 / azure_sdk_core)
- [ ] #4231 — Migration guide: `azure_identity` (from azure_identity ≤0.21.0 / azure_sdk_auth_aad)
- [ ] #4229 — Migration guide: `azure_security_keyvault_secrets` (from azure_security_keyvault)
- [ ] #4232 — Migration guide: `azure_security_keyvault_keys` (from azure_security_keyvault)
- [ ] #4234 — Migration guide: `azure_security_keyvault_certificates` (from azure_security_keyvault)
- [ ] #4236 — Migration guide: `azure_messaging_eventhubs` (from azeventhubs)
- [ ] #4233 — Migration guide: `azure_data_cosmos` (from azure_data_cosmos ≤0.21.0 / azure_sdk_cosmos)
- [ ] #4237 — Migration guide: `azure_storage_blob` (from azure_storage_blobs / azure_sdk_storage_blob)
- [ ] #4235 — Migration guide: `azure_storage_queue` (from azure_storage_queues)

> **Note:** Migration guide for `azure_messaging_servicebus` is deferred until the era 3 rewrite is published on crates.io.

### Priority

1. **GA crates first (April 2026):** Identity, Key Vault (Secrets, Keys, Certificates), Event Hubs, Storage Blob
2. **Near-GA:** Core (infrastructure for all crates), Cosmos DB (June 2026), Storage Queue
3. **Deferred:** Service Bus (era 3 rewrite not yet published)

### Acceptance Criteria

- [x] All 9 sub-issues filed and linked
- [ ] Each migration guide published in repo docs
- [ ] Each guide includes code samples for key scenarios
- [ ] Each guide linked from the relevant crate README

---

## Migration Guide Best Practices (Recommended Structure)

> Distilled from 12 migration guides across the four Tier 1 Azure SDK languages (.NET, Java, JavaScript/TypeScript, Python). Adapted for Rust idioms.

### Recommended Table of Contents

Every Rust crate migration guide **MUST** follow this heading structure. Adapt heading text to fit the specific crate, but preserve the order and intent of each section.

```
# Migrating to {new_crate} from {old_crate}

## Table of Contents
(auto-generated from headings)

## Why Migrate
- Deprecation notice for the old crate/version
- Key benefits: unified Azure SDK design, stable API, active maintenance
- Cross-service improvements (shared azure_core pipeline, azure_identity, OpenTelemetry)

## General Changes

### Crate Name and Cargo.toml
- Old vs. new Cargo.toml dependency lines (side-by-side diff)
- Feature flags (`enable_reqwest`, `enable_reqwest_rustls`, `hmac_rust`, `hmac_openssl`, etc.)
- If the crate was renamed: explain the name change and any `azure_storage_common` / `azure_core` re-exports

### use Statements and Module Layout
- Old imports → new imports (side-by-side)
- Module restructuring (e.g., `azure_security_keyvault` monolith → three crates)

### Authentication
- Old auth pattern (connection strings, manual tokens, etc.)
- New auth pattern using `azure_identity::DefaultAzureCredential`
- Other credential types: `ClientSecretCredential`, `ManagedIdentityCredential`, etc.
- Call out the KEY → Microsoft Entra ID (AAD) transition where applicable

### Client Construction
- Old client instantiation
- New builder-pattern or constructor-based instantiation
- Configuration via options structs (retry, transport, timeout)

## Common Scenarios
(One subsection per operation — use ### headings)

### Creating / Initializing a Resource
### Reading / Getting a Resource
### Listing Resources (Pagination)
### Updating / Setting a Resource
### Deleting a Resource
### (Service-Specific Operations)
- e.g., "Sending Events" for Event Hubs, "Cryptographic Operations" for Key Vault Keys

Each scenario shows:
1. Old code (```rust fenced block, with comment "// Before: {old_crate}")
2. New code (```rust fenced block, with comment "// After: {new_crate}")

## Error Handling
- Old error types → new `azure_core::Error` / crate-specific error types
- `Result` pattern
- How to match on error kinds

## Async Runtime and Concurrency
- `tokio` runtime requirement
- Old async story (if any) → new async/.await patterns
- Sync wrappers (if available)
- Cancellation patterns (drop-based cancellation in Rust)

## Feature Flags
- Table of available Cargo feature flags and what they enable
- Default features vs. optional features
- Example: switching TLS backend (`enable_reqwest_rustls` vs default OpenSSL)

## Additional Resources
- Link to crate README (in-repo)
- Link to `examples/` directory (in-repo)
- Link to API docs on docs.rs
- Link to CHANGELOG.md
- Link to Azure SDK Design Guidelines for Rust
```

### Cross-Language Reference Table

The recommended structure above was distilled from the following migration guides across Tier 1 Azure SDK languages:

| Language | Service | Guide URL |
|----------|---------|-----------|
| **.NET** | Storage Blobs | [AzureStorageNetMigrationV12.md](https://github.com/Azure/azure-sdk-for-net/blob/main/sdk/storage/Azure.Storage.Blobs/AzureStorageNetMigrationV12.md) |
| **.NET** | Key Vault Secrets | [MigrationGuide.md](https://github.com/Azure/azure-sdk-for-net/blob/main/sdk/keyvault/Azure.Security.KeyVault.Secrets/MigrationGuide.md) |
| **.NET** | Event Hubs | [MigrationGuide.md](https://github.com/Azure/azure-sdk-for-net/blob/main/sdk/eventhub/Azure.Messaging.EventHubs/MigrationGuide.md) |
| **Java** | Key Vault Secrets | [migration_guide.md](https://github.com/Azure/azure-sdk-for-java/blob/main/sdk/keyvault/azure-security-keyvault-secrets/migration_guide.md) |
| **Java** | Key Vault Keys | [migration_guide.md](https://github.com/Azure/azure-sdk-for-java/blob/main/sdk/keyvault/azure-security-keyvault-keys/migration_guide.md) |
| **Java** | Key Vault Certificates | [migration_guide.md](https://github.com/Azure/azure-sdk-for-java/blob/main/sdk/keyvault/azure-security-keyvault-certificates/migration_guide.md) |
| **JavaScript** | Event Hubs | [migrationguide.md](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/eventhub/event-hubs/migrationguide.md) |
| **JavaScript** | Service Bus | [migrationguide.md](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/servicebus/service-bus/migrationguide.md) |
| **JavaScript** | Storage Blob | [MigrationGuide.md](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/MigrationGuide.md) |
| **Python** | Event Hubs | [migration_guide.md](https://github.com/Azure/azure-sdk-for-python/blob/main/sdk/eventhub/azure-eventhub/migration_guide.md) |
| **Python** | Key Vault Keys | [migration_guide.md](https://github.com/Azure/azure-sdk-for-python/blob/main/sdk/keyvault/azure-keyvault-keys/migration_guide.md) |
| **Python** | Storage Blob | [migration_guide.md](https://github.com/Azure/azure-sdk-for-python/blob/main/sdk/storage/azure-storage-blob/migration_guide.md) |

**Cross-language patterns observed:**
- All 12 guides follow the same general flow: Why → Package/Import changes → Auth → Client construction → Scenarios → Samples.
- All use side-by-side old/new code snippets for every common operation.
- All prominently feature `DefaultAzureCredential` (or language equivalent) as the recommended auth.
- All link to samples, API reference, and design guidelines.

### Rust-Specific Adaptations

#### Cargo.toml Diffs

Show `Cargo.toml` changes as a diff block. For crate renames, show removal + addition:

```diff
# Before (era 2)
- azure_storage_blobs = "0.21"
- azure_storage = "0.21"

# After (era 3 / GA)
+ azure_storage_blob = "0.11"
+ azure_identity = "0.34"
```

For same-crate version bumps (e.g., `azure_core`), show the version change:

```diff
- azure_core = "0.21"
+ azure_core = "0.34"
```

#### Handling the Three-Era Split

Some sub-issues map **old crate → new crate** (different names), others map **old version → new version** (same name). The guide structure handles both:

| Migration Type | Example | Key Difference in Guide |
|----------------|---------|------------------------|
| **Different crate name** | `azure_storage_blobs` → `azure_storage_blob` | "Crate Name and Cargo.toml" section shows crate rename + explains why |
| **Same crate, version bump** | `azure_core` ≤0.21 → 0.34 | "Crate Name and Cargo.toml" shows version change; emphasize API break at 0.22.0 |
| **Community crate → official** | `azeventhubs` → `azure_messaging_eventhubs` | Lead with "this is a different crate by a different team"; explain that APIs will differ significantly |
| **Monolith → split** | `azure_security_keyvault` → secrets/keys/certs | Explain the split rationale; cross-link sibling guides |

#### Code Sample Conventions

- Use ` ```rust ` fenced code blocks for all Rust samples
- Include `use` statements at the top of each snippet so readers can copy-paste
- Use `#[tokio::main]` or `tokio::runtime::Runtime` in examples to show async setup
- Show `Result<(), Box>` return types (or `azure_core::Result<()>` where appropriate)
- If a feature flag is required, include a comment: `// Requires: azure_identity = { version = "0.34", features = ["enable_reqwest"] }`
- When showing `cfg` feature gates, use:
```rust
// In Cargo.toml: azure_storage_blob = { version = "0.11", features = ["enable_reqwest_rustls"] }
```

#### Linking to Examples

Each guide should link to the crate's `examples/` directory in the repo:

```
See the [examples directory](https://github.com/Azure/azure-sdk-for-rust/tree/main/sdk/{service_area}/{crate_name}/examples) for runnable samples.
```

### Quality Bar Checklist

Every migration guide **MUST** satisfy all items below before merging:

- [ ] **Compilable code samples** — every `rust` code block compiles against the current crate version (verified via `cargo check --examples` or CI)
- [ ] **Side-by-side before/after** — every common operation shows old code and new code in adjacent fenced blocks
- [ ] **Cargo.toml diff** — includes a clear diff showing the old dependency line(s) and the new dependency line(s)
- [ ] **Authentication migration** — explicitly covers the transition from old auth patterns (connection strings, manual tokens, key-based) to `azure_identity::DefaultAzureCredential` and Microsoft Entra ID
- [ ] **Error handling section** — documents old error types → new `azure_core::Error` types, with a match example
- [ ] **API docs link** — links to the crate's docs.rs page (e.g., `https://docs.rs/azure_storage_blob/latest/`)
- [ ] **Examples directory link** — links to the in-repo `examples/` folder for the crate
- [ ] **Feature flags table** — lists all Cargo feature flags with descriptions, especially TLS backend choices
- [ ] **Async runtime callout** — states the `tokio` requirement and shows `#[tokio::main]` in at least one example
- [ ] **No dead links** — all links in the guide resolve (verified before merge)

Start with the nine linked sub-issues and inspect each crate's README, examples directory, CHANGELOG.md, and docs.rs page. Use the specified migration-guide structure and verify Rust samples with cargo check --examples. Done means all nine guides are published, linked from their crate READMEs, and meet the quality checklist without dead links.

Written by the indexing model from the issue text.