[EPIC] Re-platform Azure VS Code extensions onto azd

## Problem statement

Azure's VS Code extensions each handle resource creation and management independently, with direct ARM calls, custom Bicep handling, and separate authentication flows. This means new `azd` capabilities (like AI agent support or extension-based provisioning) don't automatically benefit the VS Code ecosystem, and developers working across extensions encounter different patterns for similar tasks.

We're exploring a model where `azd` serves as a shared resource creation layer for VS Code extensions. When a developer creates resources from the command palette and later uses `azd` for deployment, the two should work together seamlessly: one project, one workflow.

## Vision

Azure VS Code extensions use `azd` as their resource creation and project management layer. One extension proves the model first, demonstrating that `azd` can replace custom ARM calls, provide a consistent "turn this into an `azd` project" flow, and reduce extension-side complexity. If the PoC succeeds, it becomes the playbook for every Azure VS Code extension to follow.

## Who this helps

- **Azure developers using VS Code**: Get a consistent experience whether creating resources from the command palette or the terminal. A VS Code project *is* an `azd` project from the start, with no migration or conversion step needed.
- **VS Code extension developers**: Instead of maintaining custom ARM/Bicep resource creation code, call `azd` APIs and get provisioning, deployment, and project management capabilities built in. Ship features faster.
- **Platform engineers**: Benefit from consistent project structure across the team, regardless of whether developers work in the terminal or VS Code.

## Goals (in scope)

- Validate that `azd` can serve as the resource creation layer for Azure VS Code extensions through a successful PoC with one extension team
- Deliver a PoC where **one** Azure VS Code extension uses `azd` for resource creation instead of its own ARM calls
- Validate the "turn this into an `azd` project" flow from within VS Code by creating an `azd` project from an existing VS Code workspace
- Document the integration pattern so other extension teams can follow

## Non-goals (out of scope)

- Full re-platform of all Azure VS Code extensions; this is PoC scope only
- The `azd` team doing the extension-side integration work; the Azure VS Code extension team owns this, with support from `azd` as needed
- Replacing VS Code extension UI/UX; `azd` provides the backend, extensions own their front-end
- JSON-RPC or advanced protocol integration; shell-out works today and is sufficient for PoC

## Success criteria

- [ ] "Turn this into an `azd` project" flow works from VS Code for the PoC extension
- [ ] Integration pattern documented: how an extension calls `azd`, what APIs are used, what the developer experience looks like
- [ ] PoC evaluation completed with clear go/no-go recommendation for broader rollout
>Note
>Verify these with Matt

## Dependencies

- **VS Code extension teams**: This is a partnership, not a unilateral move. Extension owners must agree to participate and allocate time for the PoC. Discovery meeting is the gate.
- **Extension Framework GA (Pillar 3)**: The long-term re-platform story depends on stable extension APIs. PoC can use current capabilities, but broader rollout needs GA.
- **`azd` project model**: The "turn this into an `azd` project" flow assumes `azd`'s project model (azure.yaml) is stable and expressive enough for extension use cases.