Support existing container builds for Spring Boot applications

Extend the `azure.springboot` extension to support Spring Boot projects that already define how their container image is built. The extension should preserve an existing Dockerfile, Maven Jib configuration, or Gradle Jib configuration rather than replacing it with the extension’s default buildpack-based path.

The application remains the source of truth for its container build. The extension should detect supported container-build configuration, use it through the standard `azd deploy` and `azd up` workflows, and apply the same Azure Container Apps deployment, identity, configuration, health, and observability behavior used for buildpack deployments.

We need to:

- Implement all Spring Boot-specific container-build behavior in `cli/azd/extensions/azure.springboot/`.
- Detect supported container-build configuration:
- Dockerfiles
- Maven Jib plugin
- Gradle Jib plugin
- Associate each container-build definition with the correct Spring Boot service in single-module and multi-module projects.
- Prefer an explicit build configuration over the extension’s inferred buildpack path.
- Define and document deterministic precedence when more than one supported container-build method is present.
- Require explicit configuration when the correct build method cannot be determined safely.
- Preserve the application’s existing Dockerfile path, build context, target stage, image entry point, arguments, and supported build arguments.
- Preserve existing Maven and Gradle Jib configuration.
- Use the Maven or Gradle wrapper when present and an installed build tool otherwise.
- Build and publish the image through the existing azd container build and deployment workflow where possible.
- Use Azure Container Registry when the selected deployment path requires a registry.
- Authenticate builds and deployments without persisting registry credentials.
- Preserve the detected application port, management port, context path, and health endpoints.
- Apply the existing Spring Boot configuration mappings, managed identity, role assignments, scaling, and observability behavior to the resulting Container App.
- Respect explicit image names and tags when they are compatible with the standard azd deployment workflow.
- Produce deterministic image metadata and deployment configuration for the same project, source revision, and extension version.
- Explain which build method was selected, why it was selected, and which project file or plugin supplied it.
- Validate that the resulting image architecture is compatible with the deployment target.
- Validate that the image exposes or listens on a port compatible with the inferred service configuration.
- Validate that the image has a usable entry point and includes a supported Java runtime.
- Return actionable guidance for missing build contexts, invalid Dockerfiles, unsupported Jib configuration, unavailable registries, and failed image builds.
- Add fixtures and table-driven tests covering:
- A root Dockerfile
- A module-specific Dockerfile
- A multi-stage Dockerfile
- Maven Jib
- Gradle Jib
- Multiple supported build methods
- Explicit build-method selection
- Invalid build contexts
- Unsupported image architectures
- Add end-to-end coverage proving that representative Dockerfile, Maven Jib, and Gradle Jib projects deploy through standard `azd up` and `azd deploy` workflows.
- Verify that repeated `azd up` operations do not rebuild or replace images without a relevant source or configuration change where the underlying azd workflow supports that behavior.
- Document supported container-build methods, precedence, registry behavior, configuration, and known limitations in `cli/azd/extensions/azure.springboot/README.md`.
- Link this issue as blocked by the Spring Boot project detection, project translation, Azure Container Apps deployment, Maven, Gradle, configuration mapping, validation, and observability issues.

## Boundaries

- Do not add Spring-specific commands or verbs.
- Do not add an `azd spring` command namespace.
- Do not add extension-specific image, container, or build commands.
- Do not modify azd core behavior.
- Do not rewrite, generate, or replace an existing Dockerfile.
- Do not modify Maven or Gradle build files, Jib configuration, Java source, or Spring configuration.
- Do not inject Jib into a project that does not already use it.
- Do not silently choose between conflicting container-build definitions.
- Do not require a checked-in Dockerfile when the project uses Jib.
- Do not require Jib when the project uses a Dockerfile.
- Do not persist registry usernames, passwords, or access tokens.
- Do not add Docker Compose or Kubernetes manifest support in this issue.
- Do not add new deployment targets.
- Do not target Azure Spring Apps.
- If the extension framework cannot use these build methods 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 with cli/azd/extensions/azure.springboot/README.md and the extension directory, then review the linked Spring Boot detection, translation, deployment, validation, and observability work. Add the requested fixtures, table-driven tests, and end-to-end coverage for standard azd up and azd deploy workflows. Done means supported Dockerfile, Maven Jib, and Gradle Jib projects are handled deterministically and the README documents selection, precedence, registry behavior, and limitations.

Written by the indexing model from the issue text.