Validate the end-to-end Spring Boot experience

Validate that the `azure.springboot` extension provides a complete, reliable experience for taking an existing Maven-based Spring Boot application from source code to a running application in Azure Container Apps using the standard `azd init` and `azd up` workflows.

This issue brings the initial extension capabilities together and establishes the quality bar for a preview release. It should verify that detection, project translation, infrastructure provisioning, application deployment, configuration mapping, and diagnostics work as one coherent experience. It should also use feedback from early adopters to identify gaps before the extension is made broadly discoverable.

We need to:

- Create a representative end-to-end test application under the extension’s test assets.
- Ensure the application starts as a normal Spring Boot project without existing azd configuration or Azure-specific infrastructure.
- Use Maven and produce an executable JAR.
- Include Spring Boot Actuator health endpoints.
- Exercise the initial supported Azure integrations:
- Azure Database for PostgreSQL
- Azure Service Bus
- Azure Storage
- Azure Key Vault
- Validate the complete first-run experience using standard azd commands:
- `azd init`
- `azd up`
- `azd provision`
- `azd deploy`
- `azd down`
- Verify that `azd init` recognizes the Spring Boot project through the extension and produces a deterministic project model.
- Verify that the developer is not required to choose a deployment host, write infrastructure, create a Dockerfile, or manually map Azure outputs to Spring configuration.
- Verify that `azd up` provisions the expected resources, builds the application, deploys it to Azure Container Apps, and reports a working endpoint.
- Verify that the deployed application passes its readiness and liveness checks.
- Verify that the application can access each backing Azure service using managed identity and least-privilege role assignments.
- Verify that no connection strings, passwords, access keys, or other long-lived credentials are generated or persisted.
- Verify that application logs, JVM metrics, and deployment diagnostics are available through the expected Azure Container Apps and Azure Monitor experiences.
- Verify that a second `azd up` is idempotent and does not replace resources or change inferred configuration without cause.
- Verify that `azd deploy` updates application code without unnecessarily reprovisioning infrastructure.
- Verify that `azd provision` updates infrastructure without unnecessarily rebuilding or redeploying the application.
- Verify that `azd down` removes resources created by the test project.
- Validate interactive and `--no-prompt` workflows.
- Validate the experience on the operating systems supported by first-party azd extensions.
- Add failure-path coverage for unsupported Java versions, failed Maven builds, missing Azure permissions, unavailable regions, failed health checks, and invalid explicit overrides.
- Ensure failures identify the affected service and provide an actionable next step without exposing secrets.
- Record the expected resource graph, inferred project model, and user-visible output as test artifacts for diagnosing regressions.
- Identify at least two early adopters with existing Spring Boot applications that are representative of the initial scope.
- Validate the extension against those applications without committing customer code, configuration, names, or identifying information to the repository.
- Track feedback and defects as separate issues under the Spring Boot epic.
- Define the minimum quality and reliability criteria required before publishing the preview extension beyond the nightly registry.
- Document the validated workflow, supported scenario, limitations, and troubleshooting guidance in `cli/azd/extensions/azure.springboot/README.md`.
- Link this issue as blocked by the extension foundation, project detection, project translation, Azure Container Apps deployment, configuration mapping, and composable resource issues.

## 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 fix missing extension-framework capabilities as part of this issue.
- Do not broaden the initial product scope while resolving test failures.
- Do not add Gradle, WAR, App Service, AKS, Azure Functions, Azure Red Hat OpenShift, or VM support.
- Do not target Azure Spring Apps.
- Do not add Azure integrations beyond PostgreSQL, Service Bus, Storage, and Key Vault.
- Do not add application modernization, dependency upgrades, or source-code transformation.
- Do not make the extension broadly discoverable until the preview quality criteria are met.
- Do not include customer names, source code, configuration, telemetry, or other identifying information in the repository or GitHub issues.
- If validation exposes a core or extension-framework gap, file it against the appropriate core epic rather than adding a workaround, parallel command, or core change in this issue.

Start with cli/azd/extensions/azure.springboot/README.md and the extension’s test assets, then review the standard azd init, up, provision, deploy, and down workflows. Done means the representative Maven Spring Boot application passes the listed success and failure-path checks across supported operating systems, with resource graphs, project models, diagnostics, and user-visible output recorded as artifacts. Update the README with the validated workflow, limitations, and troubleshooting guidance.

Written by the indexing model from the issue text.