Deploy Spring Boot applications to Azure Container Apps

Add Azure Container Apps deployment support to the `azure.springboot` extension. A detected Spring Boot application should work with the standard `azd provision`, `azd deploy`, and `azd up` workflows without requiring the developer to write a Dockerfile, Bicep, or Azure-specific application configuration.

Azure Container Apps should be the default deployment target for the first version of the extension. The extension should translate Spring Boot project information into a secure, observable, production-capable Container Apps deployment while preserving standard Maven and Spring Boot conventions.

We need to:

- Implement all Spring Boot-specific behavior in `cli/azd/extensions/azure.springboot/`.
- Use the project model produced by the Spring Boot project translation issue.
- Use Azure Container Apps as the default deployment target.
- Support Maven-based executable JAR applications.
- Build applications using the Maven wrapper when present and an installed Maven executable otherwise.
- Respect the module, artifact, Java version, packaging, and build configuration discovered from the Spring Boot project.
- Use a supported buildpack-based path to produce the application image without requiring a checked-in Dockerfile.
- Generate or synthesize the extension-owned infrastructure required for:
- An Azure Container Apps environment
- One Container App for each detected Spring Boot service
- A container registry when required by the selected build and deployment path
- Log Analytics and Azure Monitor integration
- Managed identity
- Required role assignments
- Configure ingress from the detected application port.
- Configure readiness and liveness probes from Spring Boot Actuator health endpoints when available.
- Use safe defaults when Actuator is not present and clearly report which health behavior was selected.
- Configure CPU and memory defaults appropriate for a Spring Boot application.
- Enable JVM memory fitting where supported.
- Default latency-sensitive HTTP applications to at least one replica rather than silently enabling scale-to-zero.
- Allow explicit azd project configuration to override inferred CPU, memory, scaling, ingress, and health settings.
- Use the Java version detected from the project and fail with actionable guidance when it is unsupported by the selected build path.
- Pass runtime configuration through environment variables using Spring Boot-compatible property naming.
- Send application logs to standard output and standard error so they are available through Container Apps logging.
- Surface the deployed application endpoint through the normal `azd` service endpoint experience.
- Produce deterministic infrastructure and deployment configuration for the same project and extension version.
- Explain inferred deployment decisions, including the selected port, health endpoints, Java version, resource sizing, and scaling behavior.
- Add fixtures and tests covering a basic web application, an Actuator-enabled application, a multi-module project, unsupported Java versions, missing build artifacts, and failed health checks.
- Add an end-to-end test that provisions and deploys a representative Spring Boot application through `azd up`.
- Document supported Java and Spring Boot versions, build behavior, generated Azure resources, scaling defaults, observability, and known limitations in `cli/azd/extensions/azure.springboot/README.md`.
- Link this issue as blocked by the `azure.springboot` extension foundation, Maven project detection, and Spring Boot project translation 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 add Spring-specific behavior to the built-in Container Apps service target.
- Do not require a checked-in Dockerfile for the initial supported path.
- Do not modify the application’s Java source, Maven configuration, or Spring configuration.
- Do not add Spring Cloud Azure dependencies to the application.
- Do not provision databases, caches, messaging services, or other backing Azure resources in this issue.
- Do not implement App Service, AKS, Azure Functions, Azure Red Hat OpenShift, or VM deployment targets.
- Do not target Azure Spring Apps, which retires on March 31, 2028.
- Do not add Gradle or WAR deployment support in this issue.
- Do not silently select scale-to-zero for an HTTP application.
- Do not store Azure credentials, connection strings, or secrets in generated files.
- If the extension framework cannot support the required standard `azd` workflow, file the gap 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/ and read its README plus the azure.springboot extension foundation, Maven project detection, and Spring Boot project translation issues. Trace the project model and standard azd provision, deploy, and up entry points before defining the Container Apps, build, health, scaling, and configuration behavior. Done means the listed fixtures and tests, the azd up end-to-end test, deterministic generated configuration, and updated README are complete.

Written by the indexing model from the issue text.