Microsoft.Validate end-to-end process to onboard a new module for a new RP to public preview

### Description

**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 from it. Targeting **public preview by Aug 15, 2026**. We plan an **auto-gen** module (`Az.Validate`) via autorest.powershell.

Questions:

1. **Onboarding:** What's the end-to-end process to onboard a new module for a new RP to public preview?
2. **TypeSpec input:** For a TypeSpec-only RP, what's the supported `autorest.powershell` input — do we compile TypeSpec → swagger and point `input-file` at that, or is there a TypeSpec-native path?
3. **Timing:** Can we generate + iterate now from the private spec (RPSaaSMaster), with the public release gated on graduation to public `azure-rest-api-specs`?
4. **Branch:** Do auto-gen module PRs still target the `generation` branch, or `main` now?
5. **Design review:** Where + when does the cmdlet design review happen, and what's the typical timeline?
6. **Release:** What's the preview release process to the PowerShell Gallery (target branch, sprint master)?

### Script or Debug output

```PowerShell
N/A - process/onboarding question, not a bug.
```

### Environment data

```PowerShell
N/A
```

### Module versions

```PowerShell
N/A
```

### Error output

```PowerShell
N/A
```

The issue names autorest.powershell, RPSaaSMaster, azure-rest-api-specs, and the generation/main branches, but no repository file or test. Start by locating existing module-onboarding and preview-release guidance; document the supported TypeSpec input, branch, design-review, and PowerShell Gallery steps, including public-preview gating.

Written by the indexing model from the issue text.