[EPIC] Let extensions emit telemetry through azd

## Summary

Extension authors have no first-party way to emit their own telemetry today, outside of structured error reporting (for example, https://github.com/Azure/azure-dev/pull/6321). This epic delivers a host-mediated telemetry SDK so extensions can emit events through azd without taking a direct dependency on AppInsights or writing payloads to disk themselves.

## Goal

Give extension authors something equivalent in spirit to VS Code's [`@vscode/extension-telemetry`](https://github.com/microsoft/vscode-extension-telemetry): an author declares telemetry configuration in the extension manifest, calls a small SDK, and azd handles opt-out, redaction, anonymization, persistence, batching, and upload.

## Scope

- **Host-owned upload pipeline**: the extension subprocess calls a small gRPC API on the host. The host validates, redacts, stamps identity/anonymization, and routes to the configured destination. Extensions do not embed AppInsights or own a disk queue.
- **Manifest-declared destination**: telemetry is opt-in per extension via manifest configuration plus a telemetry capability. The host validates the destination (HTTPS, allowlisted Azure Monitor/Application Insights ingestion suffixes, no loopback/private hosts).
- **Identity from the host**: extension identity is derived from validated extension claims, never from request payloads. Host stamps `extension.id`, `extension.version`, machine identity, and common resource attributes; extensions cannot override reserved fields.
- **Storage shape that supports multiple destinations**: azd's existing telemetry queue is reorganized so extensions can enqueue to a non-azd endpoint without colliding with azd's own data.
- **Alpha gate**: require `alpha.extension.telemetry` plus an installed telemetry capability/configuration. Disabled telemetry, unsupported hosts, or missing capability must be a no-op for extension commands.
- **First-party dogfood**: validate the full pipeline by adopting it in a first-party extension before considering broader enablement.

## Threat model and guardrails

- Malicious connection-string redirect — host-side parse/validate/allowlist of ingestion endpoints.
- PII leakage via extension events — host-side redaction (shared with #8016), reserved-key filtering, default classification for extension-provided properties.
- Extension identity spoofing — derive identity from validated claims and installed metadata, not request payloads.
- Manifest integrity — extensions are checksum-verified by the registry, but manifests are not separately signed; security review required before third-party enablement.

## Out of scope (for now)

- Client-streaming RPC and reporter sessions — start with unary `Track` + `Flush`; revisit only if dogfood shows volume/lifecycle pressure that justifies the complexity.
- Per-reporter token buckets — start with simple per-extension/global payload caps.
- Public SDK documentation, transparency artifacts (e.g. a `telemetry.json` declaration of emitted events), consent UX, and `alpha` → stable graduation — follow-ups after first-party dogfood.
- Third-party / non-Microsoft extension enablement — gated on the follow-ups above plus security/privacy review.
- Template-level telemetry (#5915).

## References

- Closes / supersedes: #6223, #4391 (closed; reference only), #7959 (related)
- Prior PRs: #6835 (`azdext.Run` reference shape), #6901
- Related: #8016 (PII redactor reused by this pipeline)
- VS Code precedent: `microsoft/vscode-extension-telemetry`, https://code.visualstudio.com/api/extension-guides/telemetry