Add managed Spring components for Azure Container Apps

Add support for Azure Container Apps managed Spring components to the `azure.springboot` extension. Applications that use Spring Cloud Config, Eureka service discovery, Spring Cloud Gateway, or Spring Boot Admin should be able to use the corresponding managed Container Apps component without manually creating, binding, or configuring it.

The extension should infer applicable components from the Spring Boot project model, explain what it found, and use the standard `azd provision`, `azd deploy`, and `azd up` workflows. Explicit project configuration must remain authoritative, and no managed component should be provisioned unless the application uses it or the developer explicitly selects it.

We need to:

- Implement all managed Spring component behavior in `cli/azd/extensions/azure.springboot/`.
- Support the Azure Container Apps managed implementations of:
- Config Server for Spring
- Eureka Server for Spring
- Gateway for Spring
- Admin for Spring
- Use Spring dependencies and configuration identified during project detection to determine which components apply.
- Represent each managed component as extension-owned infrastructure associated with the appropriate application layer.
- Bind each component only to the Spring Boot services that use it.
- Translate component endpoints and binding information into the Spring Boot configuration expected by each application.
- Preserve explicit Spring and azd configuration over inferred values.
- Report conflicts between existing application configuration and managed component configuration.
- Allow developers to explicitly disable an inferred component.
- Allow supported component settings to be overridden through extension-owned project configuration.
- Use managed identity and least-privilege role assignments where supported.
- Avoid generating or persisting credentials when identity-based access is available.
- Produce deterministic infrastructure, bindings, and configuration for the same project and extension version.
- Explain which component was selected, what project evidence caused it to be selected, which services are bound to it, and which configuration values are supplied.
- Validate component availability in the selected Azure region before provisioning.
- Fail with actionable guidance when a component is unavailable, incompatible with the application, or requires unsupported configuration.
- Support multiple Spring Boot services sharing the same managed component when the detected project model establishes that relationship.
- Avoid creating duplicate components when repeated detection identifies the same logical dependency.
- Add fixtures and tests for each supported component, explicit selection, explicit disablement, shared components, conflicting configuration, unsupported regions, and partial application support.
- Add end-to-end coverage proving that representative Spring Boot applications can use each managed component after deployment through `azd up`.
- Verify that repeated `azd up` operations do not duplicate or unexpectedly replace components.
- Verify that `azd down` removes extension-created managed components.
- Document supported Spring dependencies, inferred behavior, generated resources, configuration mappings, regional limitations, pricing considerations, and override behavior in `cli/azd/extensions/azure.springboot/README.md`.
- Link this issue as blocked by the Azure Container Apps deployment, Spring Boot project detection, project translation, configuration mapping, and layered provisioning issues.

## Boundaries

- Do not add Spring-specific commands or verbs.
- Do not add an `azd spring` command namespace.
- Do not modify azd core behavior.
- Do not add managed Spring components to the built-in Container Apps service target or resource catalog.
- Do not provision a component solely because it is available in Azure Container Apps.
- Do not silently replace an application-managed Config Server, Eureka server, gateway, or administration service.
- Do not modify Maven or Gradle build files, Java source, or Spring configuration.
- Do not automatically add or replace Spring dependencies.
- Do not generate passwords, access keys, connection strings, or other long-lived credentials.
- Do not write secrets into project files, command output, or telemetry.
- Do not add support for self-hosted Spring components in this issue.
- Do not add App Service, AKS, Azure Functions, Azure Red Hat OpenShift, or VM behavior.
- Do not target Azure Spring Apps.
- If the extension framework cannot provision or bind these components 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 in cli/azd/extensions/azure.springboot/ and read its README plus the blocked Azure Container Apps deployment, Spring Boot detection, project translation, configuration mapping, and layered provisioning issues. Run the existing extension tests and representative azd up workflows before changing behavior. Done means supported managed components are inferred, bound, configured, documented, tested end to end, and cleaned up by azd down without duplication or credential generation.

Written by the indexing model from the issue text.