[EPIC] Extension framework GA

## Problem statement

`azd` has a strong core developer workflow, and the extension framework brings the next step: a supported, stable way for any developer, internal or external, to add new capabilities. With a stable API contract, a Go SDK, and a documented submission pipeline, extension developers can build confidently, knowing their extensions will work reliably across `azd` releases. This issue represents the goal to GA the framework by end of May 2026.

## Vision

A developer can build an azd extension, test it locally, and have the confidence that the frame work is GA. The extension framework is the foundation that every extension and custom workflow builds with to leverage `azd` core.

## Who this helps

- **Extension developers** who want stable, well-documented APIs with clear lifecycle designations (GA / Preview / Not available). They can use the Go SDK with a proper release pipeline and signing, or any gRPC language without a dedicated SDK. The framework provides a clear path from building an extension to publishing it for others to install.
- **Azure developers** who benefit from a growing ecosystem of extensions that add capabilities to azd: more integrations, faster, from more contributors.
- **Platform engineers** who need confidence that extensions are signed, versioned, and safe to deploy across teams.
- **The azd core team**, who can focus on the platform while the ecosystem provides depth. First-party extensions (like Foundry) validate the framework alongside community contributions.
- **1P teams at Microsoft** who want a CLI and dev-first experience for the workflow they are building for customers.

## Goals (in scope)

- **Stable API surface**: API freeze in April with clear capability designations (GA / Preview / Not available) so extension developers know what they can depend on
- **Go SDK as first-class**: Full SDK with release pipeline and signing; the reference implementation for how extensions are built
- **gRPC language support**: Any gRPC language works without a dedicated SDK; the protocol is the contract
- **3rd-party submission pipeline**: Documented process for external developers to submit, sign, and publish extensions
- **Documentation**: Extension authoring guide, API reference, sample extensions, and submission instructions
- **Repository structure**: One repo with clear separation of core / SDK / extensions, each with its own release pipeline

## Non-goals (out of scope)

- **SDKs for every language on day one**: Go is first-class; Python, TypeScript, etc. are added based on demand, not speculation
- **Hosting or managing third-party extensions**: We provide the submission pipeline and registry; extension developers own their code
- **Extension marketplace UI**: CLI-first discovery is sufficient for GA; a portal/marketplace is a future consideration

## Success criteria

- [ ] API surface documented with GA / Preview / Not available designations
- [ ] Go SDK published with release pipeline and signing operational
- [ ] At least one non-Go extension built and working (validates gRPC-only path)
- [ ] 3rd-party submission pipeline documented and tested with at least one external submission
- [ ] Extension authoring guide and sample extensions published
- [ ] First-party Foundry extension successfully built on the framework (validates real-world use)
- [ ] GA announcement with extension developer story

## Dependencies

- **Security team**: Extension signing infrastructure and trust model
- **Foundry extension team**: First-party consumer that validates the framework under real load (see [Foundry Extensions](foundry-extensions.md))
- **`azd ai` team**: Agent commands may surface as extensions or depend on extension APIs (see [Hosted Agents CLI](hosted-agents-cli-ga.md))