[Microsoft.Validate] Onboarding a new CLI extension (az validate) for public preview

### Context

New ARM resource provider **`Microsoft.Validate`** (product: *Compute Validation*), TypeSpec-authored, API version **`2026-07-01-preview`**, spec **merged to RPSaaSMaster** (`Azure/azure-rest-api-specs-pr` #29278). Python + .NET SDKs are already generating. Targeting **public preview by Aug 15, 2026**.

We already have an **aaz-dev-generated** extension (command group `az validate`; package currently named `computevalidation`, which we plan to rename to `validate`).

### Questions

1. **Path:** For a TypeSpec RP, is the **`typespec-aaz`** translator the recommended generation path, or should we compile TypeSpec -> swagger and generate from that?
2. **Onboarding:** What's the end-to-end process to publish the extension for **public preview**?
3. **Timing:** Can we generate + iterate now from the **private** `azure-rest-api-specs-pr` (RPSaaSMaster), with the public-index release gated on graduation to public `azure-rest-api-specs`?
4. **Naming:** Please confirm the intended naming - extension/package **`validate`** and command group **`az validate`**.
5. **Release flow:** What is the PR/review flow to public **`Azure/aaz`** (command models) and **`Azure/azure-cli-extensions`** (extension code) for the index release?

_This is a process/onboarding question, not a bug._

Start by reviewing the existing aaz-dev-generated extension, Azure/aaz command models, and Azure/azure-cli-extensions release guidance, along with azure-rest-api-specs-pr #29278. Done means the TypeSpec generation path, preview publication steps, naming, timing, and PR flow are confirmed by maintainers.

Written by the indexing model from the issue text.