Add an end-to-end Spring AI scenario

Extend the existing `azure.springboot` work to cover Spring Boot applications built with Spring AI and Azure OpenAI. This is an AI-focused version of the existing detection, project translation, configuration mapping, micro-template, validation, and end-to-end deployment work, not a separate implementation path.

We need to:

- Detect existing Spring AI dependencies and configuration in Maven and Gradle projects.
- Include Spring AI requirements in the existing Spring Boot project model.
- Map Azure OpenAI endpoints and deployment names to the Spring AI configuration expected by the application.
- Use `DefaultAzureCredential` locally and managed identity after deployment.
- Compose with existing Foundry extension capabilities for model selection, regional availability, quota, provisioning, and responsible AI policy.
- Add a Spring AI micro-template that composes with existing Spring Boot and Foundry micro-templates.
- Consider the end-to-end differences introduced by model availability, quota, deployment selection, identity, role assignments, and regional constraints.
- Validate that the selected region supports both the Spring Boot application resources and required model deployments.
- Add end-to-end coverage proving that the same application can run locally and in Azure Container Apps without API keys.
- Document the supported Spring AI versions, configuration mappings, dependencies, and known limitations.
- Link this issue to the corresponding Spring Boot detection, translation, configuration, micro-template, validation, and end-to-end issues.

## Boundaries

- Do not create a separate Spring AI architecture or project model.
- Do not duplicate the existing Spring Boot work items.
- Do not add Spring-specific or AI-specific commands or verbs.
- Do not add an `azd spring` command namespace.
- Do not duplicate model, quota, region, or responsible AI logic owned by Foundry extensions.
- Do not modify application source or build configuration.
- Do not generate, persist, or display Azure OpenAI API keys.
- Do not modify azd core behavior.
- If the scenario requires a missing core or extension capability, track it in the owning epic rather than implementing it here.

Start by reviewing the existing azure.springboot work and the corresponding Spring Boot detection, translation, configuration, micro-template, validation, and end-to-end issues. Trace how those pieces compose with the existing Foundry extensions and Spring Boot and Foundry micro-templates. Done means the listed Spring AI scenario is covered end to end, including local and Azure Container Apps execution without API keys, supported versions, mappings, and limitations.

Written by the indexing model from the issue text.