Add Gradle support for Spring Boot projects

Extend the `azure.springboot` extension to support Spring Boot applications built with Gradle. Gradle-based projects should receive the same detection, project translation, Azure Container Apps deployment, configuration mapping, and standard `azd` workflow support as Maven-based projects.

The Gradle project remains the source of truth. The extension should understand common Groovy and Kotlin DSL project structures without requiring the developer to convert the project to Maven, duplicate its structure in `azure.yaml`, or add Azure-specific build logic.

We need to:

- Implement all Gradle-specific behavior in `cli/azd/extensions/azure.springboot/`.
- Detect Gradle projects using:
- `build.gradle`
- `build.gradle.kts`
- `settings.gradle`
- `settings.gradle.kts`
- `gradlew`
- `gradlew.bat`
- Support single-project and multi-project Gradle builds.
- Recognize Spring Boot through applied plugins and resolved project metadata.
- Identify deployable Spring Boot projects without treating root aggregators, libraries, test fixtures, platforms, or build-logic projects as services.
- Identify the Java version, Spring Boot version, project path, artifact name, packaging type, and application entry point when available.
- Detect executable JAR artifacts produced by the Spring Boot `bootJar` task.
- Detect application and management ports when they are statically configured.
- Detect Spring Boot Actuator and configured health endpoints.
- Detect the same supported application dependencies and Azure integrations as the Maven implementation.
- Represent Gradle projects through the same internal Spring Boot application model used for Maven projects.
- Produce the same azd project shape for equivalent Maven and Gradle applications.
- Use the Gradle wrapper when present.
- Use an installed Gradle executable only when the wrapper is absent.
- Avoid requiring a globally installed Gradle version when the project includes a wrapper.
- Run Gradle only when necessary to resolve project metadata or build an artifact.
- Use non-interactive, deterministic Gradle invocations suitable for local development and CI.
- Respect project-defined repositories, plugins, dependency constraints, toolchains, and build configuration.
- Build the application using its existing Gradle tasks without modifying the build files.
- Deploy the resulting executable JAR through the Azure Container Apps path already implemented by the extension.
- Preserve explicit azd configuration over inferred Gradle values.
- Include provenance for values inferred from Gradle project metadata.
- Return actionable guidance for unsupported plugins, ambiguous application projects, missing wrappers, dependency-resolution failures, and build failures.
- Add representative fixtures for:
- Groovy DSL
- Kotlin DSL
- Single-project applications
- Multi-project applications
- Java toolchains
- Version catalogs
- Convention plugins
- Inherited plugin configuration
- Add table-driven tests covering successful detection, non-matches, ambiguous projects, unsupported packaging, and partial metadata.
- Add end-to-end coverage proving that a Gradle-based Spring Boot application can be initialized and deployed using standard `azd init` and `azd up` workflows.
- Document supported Gradle versions, project structures, wrapper behavior, build tasks, and known limitations 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 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 Gradle-specific commands or verbs.
- Do not modify azd core behavior or core application detection.
- Do not add a shared Gradle implementation to azd core.
- Do not require developers to convert Gradle projects to Maven.
- Do not modify `build.gradle`, `build.gradle.kts`, settings files, version catalogs, wrapper files, Java source, or Spring configuration.
- Do not inject plugins, repositories, tasks, or dependencies into the application build.
- Do not invent a second extension-owned application manifest.
- Do not add WAR deployment support in this issue.
- Do not add App Service, AKS, Azure Functions, Azure Red Hat OpenShift, or VM deployment support.
- Do not target Azure Spring Apps.
- Do not broaden the supported Azure integration set.
- Do not execute application code during detection.
- If Gradle support exposes a missing core or extension-framework capability, file it 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 Maven implementation and the extension README. Add Gradle fixtures and table-driven tests for the listed project structures and metadata cases, then add end-to-end coverage for azd init and azd up. Done means equivalent Maven and Gradle applications follow the same model and deployment workflow without modifying application build files.

Written by the indexing model from the issue text.