Add WAR packaging support for Spring Boot applications

Extend the `azure.springboot` extension to support Spring Boot applications packaged as WAR files. WAR-based projects should receive the same detection, project translation, configuration mapping, and standard `azd` workflow support as executable JAR applications.

The extension should preserve the project’s existing packaging model rather than requiring conversion to an executable JAR. It should deploy WAR applications only to supported Azure targets and fail with actionable guidance when the application depends on an unsupported servlet container or deployment model.

We need to:

- Implement all WAR-specific behavior in `cli/azd/extensions/azure.springboot/`.
- Support Maven and Gradle projects that produce deployable WAR artifacts.
- Detect WAR packaging from the project build configuration.
- Identify whether the WAR is:
- Executable through Spring Boot
- Intended for an external servlet container
- Dependent on container-specific behavior
- Identify the expected servlet container and version when available.
- Preserve the detected Java version, Spring Boot version, module path, artifact name, application port, management port, and build configuration.
- Represent WAR applications through the existing Spring Boot project model rather than introducing a WAR-specific model.
- Build applications using the Maven or Gradle wrapper when present and an installed build tool otherwise.
- Support WAR deployment to Azure Container Apps using the supported artifact or buildpack path when compatible with the application.
- Support WAR deployment to Azure App Service using the managed Tomcat runtime when explicitly selected.
- Select a compatible Java and Tomcat runtime from the detected project requirements.
- Require explicit configuration when more than one compatible runtime or deployment model is possible.
- Fail before provisioning when the application requires an unsupported servlet container, server-level configuration, shared library, native dependency, or filesystem behavior.
- Apply the existing Spring Boot configuration mappings, managed identity, and passwordless Azure service access.
- Configure ingress and health checks using the application context path, application port, management port, and Actuator configuration.
- Preserve explicit azd and application configuration over inferred values.
- Explain the detected packaging model, servlet container assumptions, selected deployment path, runtime, artifact, context path, and health endpoints.
- Produce deterministic infrastructure and deployment configuration for the same project and extension version.
- Add representative fixtures for:
- Executable Spring Boot WAR files
- WAR files intended for external Tomcat
- Maven projects
- Gradle projects
- Custom context paths
- Provided servlet-container dependencies
- Unsupported servlet containers
- Multi-module projects containing WAR and JAR applications
- Add table-driven tests covering detection, packaging classification, runtime selection, explicit overrides, ambiguous projects, missing artifacts, and unsupported application-server requirements.
- Add end-to-end coverage proving that representative WAR applications can be deployed through standard `azd init` and `azd up` workflows.
- Verify that repeated `azd up` operations are idempotent.
- Verify that `azd deploy` updates the WAR without unnecessarily reprovisioning infrastructure.
- Document supported WAR shapes, servlet containers, Java versions, deployment targets, context-path behavior, and known limitations in `cli/azd/extensions/azure.springboot/README.md`.
- Link this issue as blocked by the Spring Boot detection, project translation, Azure Container Apps deployment, Azure App Service deployment, Gradle support, configuration mapping, and end-to-end validation issues.

## Boundaries

- Do not add Spring-specific commands or verbs.
- Do not add an `azd spring` command namespace.
- Do not add WAR-specific commands or verbs.
- Do not modify azd core behavior.
- Do not modify Maven or Gradle build files, Java source, Spring configuration, or servlet-container configuration.
- Do not convert WAR applications to executable JAR applications.
- Do not add or replace Spring Boot, servlet API, or container dependencies.
- Do not silently change the application’s context path.
- Do not silently choose a servlet container when the project requirements are ambiguous.
- Do not support WebLogic, WebSphere, JBoss EAP, WildFly, or other application servers in this issue.
- Do not add AKS, Azure Functions, Azure Red Hat OpenShift, or VM deployment support.
- Do not target Azure Spring Apps.
- Do not generate passwords, connection strings, access keys, or other long-lived credentials.
- If WAR deployment requires a missing core or extension-framework capability, file the gap against the appropriate core epic rather than adding a workaround, parallel command, or core change in this issue.

Begin in cli/azd/extensions/azure.springboot/ by reading its README and tracing the existing Spring Boot project model and standard azd init, up, and deploy workflow. Use the requested representative fixtures and table-driven tests as the starting validation map; done means compatible WAR projects are detected, translated, deployed through supported targets, and documented while unsupported or ambiguous cases fail before provisioning.

Written by the indexing model from the issue text.