Translate Spring Boot projects into an azd project model

Implement project translation in the `azure.springboot` extension using the external project capability introduced by [#9839](https://github.com/Azure/azure-dev/issues/9839). The extension should translate a detected Spring Boot project into the services, relationships, and deployment requirements azd needs without requiring the developer to describe the same application again in `azure.yaml`.

The Spring Boot project remains the source of truth. `azure.yaml` should reference the project and the `azure.springboot` provider rather than contain a second, manually maintained copy of its modules and relationships. Translation must be deterministic and explainable, and the resulting project model must work with the standard `azd init`, `azd up`, `azd provision`, and `azd deploy` workflows.

We need to:

- Implement the external project provider interface from [#9839](https://github.com/Azure/azure-dev/issues/9839) in `cli/azd/extensions/azure.springboot/`.
- Translate the output of Spring Boot project detection into the azd project model.
- Represent each deployable Spring Boot module as an azd service.
- Preserve stable service identities across repeated runs, machines, and extension upgrades.
- Derive service names from Maven project metadata using documented and deterministic rules.
- Represent relationships between Spring Boot services and detected backing services.
- Preserve module paths, Java versions, packaging types, build information, application ports, management ports, and health endpoints needed by later build and deployment providers.
- Preserve Spring-specific metadata in extension-owned configuration rather than adding Spring-specific fields to the core `azure.yaml` schema.
- Allow `azure.yaml` to reference the Spring Boot project and pin the `azure.springboot` extension version.
- Treat explicit user configuration in `azure.yaml` as authoritative over inferred values.
- Report conflicts between explicit and inferred values rather than silently changing user configuration.
- Include provenance for inferred services, relationships, and configuration so azd can explain how the project model was produced.
- Provide a way to materialize the translated project model as an editable `azure.yaml` using the capability defined by [#9839](https://github.com/Azure/azure-dev/issues/9839).
- Ensure the materialized project describes the same services and relationships that azd would otherwise use in memory.
- Stop translating extension-owned project state after the user materializes and takes ownership of it, following the ownership behavior defined by #9839.
- Produce the same translated model in interactive and non-interactive environments.
- Fail with actionable guidance when the project is ambiguous and cannot be translated safely.
- Add fixtures and tests for single-service and multi-service Maven projects, explicit overrides, stable service naming, ambiguous modules, and materialization.
- Test that repeated translation produces byte-for-byte equivalent ordered output.
- Document the external project reference, override behavior, materialization behavior, and known limitations in `cli/azd/extensions/azure.springboot/README.md`.
- Link this issue as blocked by [#9839](https://github.com/Azure/azure-dev/issues/9839), the Maven-based Spring Boot detection issue, and the `azure.springboot` extension foundation issue.

## Boundaries

- Do not add Spring-specific commands or verbs.
- Do not add an `azd spring` command namespace.
- Do not modify azd core behavior or the core `azure.yaml` schema.
- Do not require users to duplicate the Spring Boot project structure in `azure.yaml`.
- Do not invent a second extension-owned application manifest.
- Do not modify Maven project files or Spring application configuration.
- Do not select Azure Container Apps, App Service, AKS, or another deployment target in this issue.
- Do not generate Bicep, Terraform, Dockerfiles, or deployment manifests.
- Do not provision or deploy Azure resources.
- Do not configure Azure service integrations.
- Do not add Gradle support in this issue.
- Do not use Azure Spring Apps as a deployment target.
- Do not silently resolve ambiguous applications, duplicate service names, or conflicting configuration.
- If the external project API cannot represent part of the Spring Boot project model, file that gap against the appropriate core epic rather than adding a workaround or modifying core in this issue.

Start in cli/azd/extensions/azure.springboot/ by reviewing the external project capability from #9839 and the Spring Boot detection output. Add the requested single- and multi-service fixtures and tests for overrides, stable naming, ambiguity, deterministic output, and materialization. Update cli/azd/extensions/azure.springboot/README.md; done means the translated and materialized models match the stated ownership and provenance behavior.

Written by the indexing model from the issue text.