[Epic] Onboard Rust to SDK Validation Pipeline in Spec Repos

## Rust Onboarding

### Goal

Enable the SDK validation pipeline in the spec repos (`azure/azure-rest-api-specs` and `azure/azure-rest-api-specs-pr`) to generate, build, and pack Rust SDK packages from TypeSpec definitions using `azsdk-cli`. This includes adding Rust support to the CLI tooling (`verify setup`, `pkg build`, `pkg pack`), integrating `azsdk-cli` into the `spec-gen-sdk-runner` orchestration layer, and wiring up the pipeline YAML to run the end-to-end flow for Rust.

### Task Breakdown

#### azsdk-cli changes (azure-sdk-tools repo)

| # | Task | Description |
|---|---|---|
| 0 | `azsdk verify setup` — Rust support | Add Rust environment validation/installation: rustup, cargo, required toolchain version, cargo extensions (e.g. cargo-fmt, cargo-clippy). Pipeline calls `azsdk verify setup --language rust` instead of manual scripting. |
| 1 | `azsdk pkg build` — Rust support | Implement Rust build logic in azsdk-cli (invoke `cargo build` with correct flags/workspace config). Or shell out to run an existed build script in Rust repo.|
| 2 | `azsdk pkg pack` — Rust support | Implement Rust packaging logic in azsdk-cli (invoke `cargo package` to produce distributable artifacts). Or shell out to run an existed build script in Rust repo. |

> **Note**: `azsdk pkg generate` already supports Rust — it invokes `tsp-client` under the hood, so no generate-side changes are needed in azsdk-cli.

> **Note**: The `verify setup` or build/pack steps may require a configuration file or script in the `azure-sdk-for-rust` repo to define prerequisite installation details (e.g., toolchain version, workspace layout). Exact requirements will be determined during implementation.

#### spec-gen-sdk-runner migration work required for Rust onboarding (azure-rest-api-specs repo)

The `spec-gen-sdk-runner` is the pipeline orchestration layer that detects changed specs, invokes SDK generation, and aggregates results. Today it shells out to `spec-gen-sdk` (TypeScript/npx). The tasks below are mostly generic runner migration work required to onboard Rust: they replace the inner call with `azsdk-cli` for TypeSpec specs, add emitter pre-checks, build command construction for generate/build/pack, capture JSON responses, and translate azsdk-cli output into the `ExecutionReport` format already used by downstream pipeline steps.

| # | Task | Description |
|---|---|---|
| 3 | Rust language key mapping | Add `azure-sdk-for-rust` → `"rust"` mapping in emitter check and adapter. |
| 4 | Emitter-enabled check (`emitter-check.ts`) | Run typespec-metadata emitter, check if `"rust"` exists in `metadata.languages`, extract packageName/outputDir. |
| 5 | ExecutionReport adapter (`azsdk-adapter.ts`) | Build ExecutionReport from azsdk-cli generate/build/pack JSON responses + typespec-metadata output. |
| 6 | OpenAPI vs TypeSpec decision gate | Rust is TypeSpec-only, so always routes to azsdk-cli path (no spec-gen-sdk fallback). |
| 7 | Command construction (`command-helpers.ts`) | Build command arrays for `azsdk pkg generate`, `azsdk pkg build`, `azsdk pkg pack`. |
| 8 | Command execution (`utils.ts`) | Generalize to capture stdout JSON for azsdk-cli commands. |
| 9 | Integration into command flow (`commands.ts`) | Wire emitter check → generate → build → pack → adapter into generation flow. |
| 10 | Unit & integration tests | Tests for emitter check, adapter, command construction, routing, end-to-end mock. |

#### Pipeline definitions and AzDO setup

| # | Task | Description |
|---|---|---|
| 11 | Pipeline YAML | Add `install-azsdk-cli.yml` step; use `azsdk verify setup --language rust` for Rust toolchain setup. |
| 12 | Create Rust SDK validation pipelines | Create new pipeline definitions for Rust in both `azure/azure-rest-api-specs` and `azure/azure-rest-api-specs-pr` repos. |

#### Validation & rollout

| # | Task | Description |
|---|---|---|
| 13 | End-to-end validation | Test with a real TypeSpec-defined Rust SDK package in the pipeline. |
| 14 | Rollout | Phase 1: enable Rust validation in the spec repos as non-blocking so failures do not prevent PR merge, and monitor run quality/stability. Phase 2: after the signal is trusted, flip the pipeline/check settings to required so Rust validation blocks PR merge on failure. |