Deploy Spring Boot applications to Azure App Service

Add Azure App Service as an alternative deployment target for the `azure.springboot` extension. App Service should provide a simpler, managed-runtime option for conventional HTTP Spring Boot applications that do not need the event-driven scaling or distributed application features of Azure Container Apps.

The extension should select App Service only when the developer explicitly configures it. Azure Container Apps remains the default target. App Service deployments must use the same detected Spring Boot project model, configuration mappings, identity model, and standard `azd provision`, `azd deploy`, and `azd up` workflows as the existing Container Apps implementation.

We need to:

- Implement all Spring Boot-specific App Service behavior in `cli/azd/extensions/azure.springboot/`.
- Use the existing Spring Boot project model rather than introducing App Service-specific detection.
- Support Maven and Gradle applications already supported by the extension.
- Support executable Spring Boot JAR deployment to the App Service Java SE runtime.
- Use the Maven or Gradle wrapper when present and the installed build tool otherwise.
- Respect the detected Java version, artifact name, module path, entry point, and build configuration.
- Require App Service to be selected through explicit azd project configuration.
- Generate or synthesize the extension-owned infrastructure required for:
- An App Service plan
- One Linux web app for each selected Spring Boot service
- Managed identity
- Required role assignments
- Application Insights and Azure Monitor integration
- Select a supported Java runtime that matches the application’s detected Java version.
- Fail with actionable guidance when the requested Java version or application shape is unsupported.
- Configure the application port and startup behavior using App Service conventions.
- Configure health checks from Spring Boot Actuator when a suitable endpoint is available.
- Use safe defaults and explain the selected behavior when Actuator is not present.
- Apply the existing Spring Boot configuration mappings to App Service application settings.
- Use managed identity and passwordless Azure service access.
- Keep secrets and long-lived credentials out of application settings, generated files, command output, and telemetry.
- Enable the App Service-managed Application Insights Java agent by default.
- Surface the deployed application endpoint through the normal `azd` service endpoint experience.
- Allow explicit project configuration to override the App Service plan SKU, instance count, health endpoint, runtime, and other supported settings.
- Explain inferred deployment decisions, including runtime, artifact, port, health endpoint, resource sizing, and monitoring configuration.
- Produce deterministic infrastructure and deployment configuration for the same project and extension version.
- Add fixtures and tests covering Maven, Gradle, Actuator-enabled, unsupported runtime, missing artifact, invalid configuration, and failed health-check scenarios.
- Add end-to-end coverage proving that a representative Spring Boot application can be provisioned and deployed to App Service through `azd up`.
- Verify that `azd deploy` updates the application without unnecessarily reprovisioning infrastructure.
- Verify that a second `azd up` is idempotent.
- Document when to choose App Service instead of Azure Container Apps, along with supported runtimes, build behavior, generated resources, scaling characteristics, observability, and known limitations in `cli/azd/extensions/azure.springboot/README.md`.
- Link this issue as blocked by the extension foundation, project detection, project translation, configuration mapping, Gradle support, and initial end-to-end validation 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 App Service service target.
- Do not make App Service the default Spring Boot deployment target.
- Do not silently select App Service based on application detection.
- Do not modify Maven or Gradle build files, Java source, or Spring configuration.
- Do not add Spring Cloud Azure dependencies to the application.
- Do not add WAR or managed Tomcat deployment support in this issue.
- Do not provision additional databases, caches, messaging services, or other backing resources.
- Do not implement AKS, Azure Functions, Azure Red Hat OpenShift, or VM deployment targets.
- Do not target Azure Spring Apps.
- Do not generate connection strings, passwords, access keys, or other long-lived credentials.
- Do not introduce an App Service-specific application model or duplicate existing Spring Boot detection and configuration logic.
- If the extension framework cannot support App Service through standard `azd` workflows, file the gap against the appropriate core epic rather than adding a workaround, parallel command, or core change in this issue.

Start in cli/azd/extensions/azure.springboot/ by reading the existing extension foundation and Container Apps implementation, then review the linked project detection, translation, configuration mapping, Gradle, and end-to-end validation work. Add App Service support without changing azd core or the built-in target, and verify the listed fixtures, deployment workflows, idempotency, health checks, and documentation in README.md.

Written by the indexing model from the issue text.