Enable azd up directly from a Spring Boot project

Allow a developer to run `azd up` from an existing Spring Boot repository that has no `azure.yaml` or Azure infrastructure. The `azure.springboot` extension should detect the application, infer the initial project and deployment configuration, and deploy it to Azure Container Apps through the standard azd workflow.

This is the main payoff of the initial extension work. The first successful run should leave behind a deterministic project definition that can be committed, reviewed, and customized. Subsequent runs should use that materialized configuration rather than repeating inference and potentially producing a different deployment.

We need to:

- Implement all Spring Boot-specific behavior in `cli/azd/extensions/azure.springboot/`.
- Use the project inference capability introduced by [#9840](https://github.com/Azure/azure-dev/issues/9840).
- Support Maven and Gradle Spring Boot project shapes already recognized by the extension.
- Invoke the existing Spring Boot detection and project translation implementations when `azd up` runs without an `azure.yaml`.
- Use Azure Container Apps as the default deployment target.
- Use the initialization provider capability from [#9837](https://github.com/Azure/azure-dev/issues/9837) to supply Spring Boot-appropriate defaults where the extension has a better answer than the developer.
- Derive a deterministic environment name from the project when one was not supplied.
- Select an Azure region that supports every resource required by the inferred project.
- Respect explicit command-line values, environment variables, and azd configuration according to the precedence rules defined by #9837.
- Validate explicit values and explain why a supplied value cannot support the inferred deployment.
- Present the inferred services, resources, deployment target, region, and source of each decision before provisioning begins.
- Clearly identify which decisions came from the `azure.springboot` extension.
- Allow the developer to inspect or cancel the inferred deployment before Azure resources are created.
- Materialize the inferred project as an `azure.yaml` during the first successful `azd up`, following the behavior defined by #9840.
- Pin the `azure.springboot` extension and its compatible version in the materialized project.
- Ensure the materialized `azure.yaml` describes the same services, resources, relationships, and deployment configuration that were presented before provisioning.
- Use the materialized project definition for subsequent `azd up`, `azd provision`, and `azd deploy` operations.
- Treat edits to the materialized project as explicit user configuration and preserve them.
- Produce deterministic materialized output for the same source project, explicit inputs, and extension version.
- Support interactive and `--no-prompt` workflows.
- In `--no-prompt` mode, fail before provisioning if the extension cannot safely resolve a required value.
- Return actionable guidance when detection is ambiguous, a required Azure service is unavailable, or the project cannot be deployed through the supported Container Apps path.
- Add fixtures and tests for:
- Maven and Gradle projects
- Single-service and multi-service projects
- Explicit subscription, location, and environment values
- Inferred defaults
- Unsupported regions
- Ambiguous detection
- Existing partial azd configuration
- Repeated `azd up` operations
- Add end-to-end coverage that starts from an unmodified Spring Boot repository with no `azure.yaml` and produces a working Azure Container Apps deployment using only `azd up`.
- Verify that the first successful run materializes deterministic project configuration.
- Verify that the second run uses the materialized configuration and does not repeat or change inference.
- Document the first-run experience, precedence rules, materialization behavior, overrides, and failure cases in `cli/azd/extensions/azure.springboot/README.md`.
- Link this issue as blocked by:
- [#9837](https://github.com/Azure/azure-dev/issues/9837) for extension-supplied initialization defaults
- [#9838](https://github.com/Azure/azure-dev/issues/9838) for extension-contributed detection
- [#9839](https://github.com/Azure/azure-dev/issues/9839) for external project translation
- [#9840](https://github.com/Azure/azure-dev/issues/9840) for project inference without `azure.yaml`
- The Spring Boot project detection and translation issues
- The Azure Container Apps deployment issue
- The Spring Boot configuration mapping issue

## Boundaries

- Do not add Spring-specific commands or verbs.
- Do not add an `azd spring` command namespace.
- Do not add an extension-specific alternative to `azd up`.
- Do not modify azd core behavior or implement the capabilities tracked by #9837, #9838, #9839, or #9840.
- Do not require the developer to run `azd init` before the first `azd up`.
- Do not keep the inferred project only in memory after a successful first deployment.
- Do not repeatedly regenerate or overwrite a materialized `azure.yaml`.
- Do not silently override explicit user configuration.
- Do not provision resources before presenting the inferred deployment.
- Do not modify Maven or Gradle build files, Java source, or Spring configuration.
- Do not require a checked-in Dockerfile.
- Do not select App Service, AKS, Azure Functions, Azure Red Hat OpenShift, or VMs by default.
- Do not target Azure Spring Apps.
- Do not generate or persist passwords, connection strings, access keys, or other long-lived credentials.
- If the standard `azd up` workflow requires additional core behavior, file that work 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/ and read its README plus the existing detection and translation implementations. Review the blocked capabilities in #9837–#9840 and the related Spring Boot and Container Apps issues before planning the integration. Done means the requested fixtures, end-to-end first and repeated azd up coverage, deterministic materialization, and README documentation are present.

Written by the indexing model from the issue text.