Add additional Azure service integrations for Spring Boot applications

Expand the `azure.springboot` extension’s composable resources and configuration mappings to cover additional Azure services commonly used by Spring Boot applications. Developers should be able to add these resources through the standard `azd add` experience and use them locally and in Azure without manually writing infrastructure, role assignments, or Spring configuration.

This issue builds on the initial PostgreSQL, Service Bus, Storage, and Key Vault integrations. It should reuse the same extension-owned templates, layered provisioning model, managed identity defaults, and configuration mapping behavior rather than introducing a second integration path.

We need to:

- Implement all Spring Boot-specific integration behavior in `cli/azd/extensions/azure.springboot/`.
- Add support for:
- Azure Database for MySQL
- Azure Managed Redis
- Azure Cosmos DB
- Azure Event Hubs
- Contribute each resource through the standard `azd add` experience.
- Use an extension-owned micro-template for each resource.
- Place each resource in its own layer so it can be provisioned, updated, and removed independently.
- Support multiple instances of the same resource type without input, output, naming, or configuration collisions.
- Detect the corresponding Maven and Gradle dependencies during Spring Boot project detection.
- Map provisioned outputs to the Spring Boot and Spring Cloud Azure properties expected by the application.
- Use Spring Cloud Azure conventions when the application already includes the applicable dependency.
- Preserve explicit application and azd configuration over inferred values.
- Report conflicts instead of silently replacing explicit configuration.
- Provision managed identity and least-privilege role assignments required by each application.
- Prefer Microsoft Entra authentication and passwordless access.
- Disable local or access-key authentication where supported and compatible with local development.
- Make non-secret configuration available to local development through standard azd environment mechanisms.
- Use `DefaultAzureCredential` for local authentication and managed identity after deployment.
- Avoid generating or exposing passwords, connection strings, access keys, or other long-lived credentials.
- Use stable, documented input and output names compatible with the existing Spring Boot configuration mapping model.
- Explain which dependency caused a resource to be inferred, which resource was added, and which Spring properties consume its outputs.
- Allow explicit project configuration to override resource names, locations, SKUs, capacity, networking, and other supported settings.
- Produce deterministic templates and configuration mappings for the same project and extension version.
- Validate required inputs before provisioning and return actionable errors for invalid or unsupported combinations.
- Add fixtures and table-driven tests for dependency detection, configuration mapping, explicit overrides, missing outputs, conflicts, and unsupported authentication modes.
- Add tests that validate each resource independently, in combination with the initial integrations, and with multiple instances of the same resource type.
- Add end-to-end coverage using `azd add` and `azd up` for a representative application integration with each service.
- Document supported dependencies, generated resources, defaults, outputs, identity requirements, configuration mappings, and cost considerations in `cli/azd/extensions/azure.springboot/README.md`.
- Link this issue as blocked by the Spring Boot detection, configuration mapping, composable resources, Maven, Gradle, and end-to-end validation issues.

## 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 add`.
- Do not modify azd core behavior, layered provisioning, or template composition.
- Do not add Spring-specific resource types to the core `azure.yaml` schema.
- Do not add these resources to azd’s built-in catalog.
- Do not modify Maven or Gradle build files, Java source, or Spring configuration.
- Do not automatically add or replace Spring Cloud Azure dependencies.
- Do not provision a resource solely because its client dependency is present when the application’s configuration indicates an external or self-hosted service.
- Do not generate passwords, connection strings, access keys, or other long-lived credentials.
- Do not write secrets into project files, command output, or telemetry.
- Do not add resources beyond MySQL, Managed Redis, Cosmos DB, and Event Hubs in this issue.
- Do not add new deployment targets.
- Do not target Azure Spring Apps.
- If the extension framework cannot contribute or configure these resources 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/ by reading the existing PostgreSQL, Service Bus, Storage, and Key Vault integrations, then review the extension README.md and linked prerequisite issues. Run the existing azd add and azd up validation paths before adding the four services. Done means independent, repeatable resource layers, mappings, identity behavior, fixtures, table-driven tests, end-to-end coverage, and documentation without changing azd core.

Written by the indexing model from the issue text.