Publish the azure.springboot extension as a public preview

Publish the `azure.springboot` extension to the default azd extension registry after the initial experience has been validated in the nightly registry. Developers should be able to discover and install the extension through the normal azd extension workflow without configuring an additional registry source.

This issue moves the extension from development preview to public preview. It should establish a clear support statement, document the supported application and deployment shapes, and ensure that we can measure reliability and adoption without collecting application code, configuration values, project names, or other customer content.

We need to:

- Publish `azure.springboot` to the default azd extension registry as a preview extension.
- Preserve `azure.springboot` as the extension ID and `Spring Boot for Azure (Preview)` as the display name.
- Verify that the published artifacts are signed and available for every operating system and architecture supported by first-party azd extensions.
- Verify installation, update, and uninstall through the standard azd extension workflow.
- Define the minimum supported azd version based on the extension capabilities used by the preview.
- Pin compatible `azdext` and shared dependency versions according to repository policy.
- Publish a preview changelog covering:
- Supported Maven and Gradle project shapes
- Supported Java and Spring Boot versions
- Azure Container Apps deployment
- Azure App Service deployment
- Supported Azure service integrations
- Managed Spring components
- Azure Spring Apps migration support
- Known limitations
- Update `cli/azd/extensions/azure.springboot/README.md` with installation, first-run, configuration, troubleshooting, and support guidance.
- Document that Azure Container Apps is the default deployment target and App Service requires explicit configuration.
- Document that Azure Spring Apps is supported only as a migration source.
- Document how inferred project and deployment decisions can be inspected and overridden.
- Document how to report bugs without including credentials, application source, or customer-identifying information.
- Add privacy-reviewed telemetry for:
- Extension version
- azd version
- Operating system and architecture
- Build system category
- Deployment target category
- Success and failure classification
- Duration measurements
- Use of supported integration categories
- Use fixed enums or hashed values where required by azd telemetry policy.
- Verify that telemetry does not collect project names, file paths, repository URLs, dependency coordinates, configuration values, resource names, endpoints, or source code.
- Add dashboards or documented queries for preview reliability, failure rates, workflow completion, and adoption.
- Define criteria for continuing, expanding, or ending the preview.
- Define the release and servicing process for preview updates.
- Define an owner rotation and response expectations for incoming issues.
- Verify that all documented scenarios have automated unit or end-to-end coverage.
- Verify that all blockers identified during early-adopter validation are resolved or documented as known limitations.
- Link this issue as blocked by the extension foundation, end-to-end validation, and all capabilities included in the public preview.

## Boundaries

- Do not add Spring-specific commands or verbs.
- Do not add an `azd spring` command namespace.
- Do not modify azd core behavior.
- Do not add new product capabilities as part of the publication work.
- Do not broaden the supported application, deployment target, or Azure integration matrix to satisfy release readiness.
- Do not mark unsupported or partially validated scenarios as supported.
- Do not remove the `(Preview)` designation.
- Do not make AKS, Azure Functions, Azure Red Hat OpenShift, or VM deployment part of the preview.
- Do not make Azure Spring Apps a deployment target.
- Do not collect customer content or identifying information through telemetry.
- Do not collect raw project names, paths, repository URLs, dependency names, resource names, endpoints, configuration values, or error payloads.
- Do not publish unsigned or partially built artifacts.
- Do not publish to the default registry until the agreed preview quality criteria are met.
- If publication requires a missing repository or extension-platform capability, file that work separately rather than including unrelated core changes in this issue.

Start with cli/azd/extensions/azure.springboot/README.md and review the extension foundation, end-to-end validation, and capability blockers named in the issue. Map the publication, support, telemetry, documentation, and coverage requirements before changing anything; done means the preview meets its quality criteria without unsupported scenarios, customer-content telemetry, or unrelated core changes.

Written by the indexing model from the issue text.