Map Azure resource configuration to Spring Boot conventions

Add Spring Boot-aware configuration mapping to the `azure.springboot` extension. When infrastructure produces an endpoint, resource name, database host, or other value, the extension should translate that output into the configuration property the application already expects instead of requiring the developer to manually connect azd environment values to Spring Boot.

The same Spring configuration should work locally and in Azure. After `azd provision`, developers should be able to run the application through Maven, Gradle, IntelliJ IDEA, or Visual Studio Code using the provisioned resources without copying values into application files or launch settings. Local development should use the developer's existing Azure identity through `DefaultAzureCredential`, while deployed applications should use managed identity.

We need to:

- Implement all Spring Boot-specific configuration behavior in `cli/azd/extensions/azure.springboot/`.
- Consume provisioned outputs through the component input and output mapping capability defined by [#9771](https://github.com/Azure/azure-dev/issues/9771).
- Translate azd environment values into Spring Boot-compatible environment variables using Spring Boot relaxed binding conventions.
- Map configuration based on the application dependencies identified during Spring Boot project detection.
- Support configuration mappings for the initial set of Azure integrations:
- Azure Database for PostgreSQL
- Azure Service Bus
- Azure Storage
- Azure Key Vault
- Prefer service endpoints, resource names, database names, namespaces, and managed identity settings over connection strings and access keys.
- Use the Spring Cloud Azure property model when the application already includes the applicable Spring Cloud Azure dependency.
- Use standard Spring Boot properties when Spring Cloud Azure is not required, such as JDBC configuration for PostgreSQL.
- Configure deployed Container Apps with the mapped environment variables and managed identity settings.
- Make the same non-secret configuration available to applications running locally through standard azd environment mechanisms.
- Support local applications started through:
- Maven Wrapper
- Gradle Wrapper
- Maven
- Gradle
- IntelliJ IDEA
- Visual Studio Code
- Do not require editor-specific project files or launch configurations to consume the mapped environment.
- Use `DefaultAzureCredential` so local applications can authenticate through an existing Azure CLI, Azure Developer CLI, IDE, or other supported developer credential.
- Keep local and deployed configuration aligned so application code does not need environment-specific authentication logic.
- Scope mapped values to the selected azd environment.
- Refresh mapped values after provisioning changes without requiring edits to the Spring Boot project.
- Ensure switching azd environments changes the local configuration without modifying application files.
- Ensure local configuration does not leak between projects or environments.
- Preserve explicit shell, IDE, Spring profile, application, and azd configuration over inferred values.
- Detect and report conflicts instead of silently replacing explicit configuration.
- Validate that the signed-in developer and deployed managed identity have the data-plane roles required by each configured integration.
- Return actionable guidance when local authentication is unavailable or authorization is incomplete.
- Keep secret values out of generated files, command output, logs, and telemetry.
- Explain which values were mapped, which Spring properties consume them, which Azure resources produced them, and whether they apply locally, in Azure, or both.
- Produce deterministic mappings for the same application model, azd environment, provisioned outputs, and extension version.
- Fail with actionable guidance when a detected dependency cannot be configured safely or requires an unsupported authentication mode.
- Add fixtures and table-driven tests for each supported integration, explicit overrides, multiple azd environments, missing or stale outputs, conflicting values, authentication failures, and unsupported authentication configurations.
- Add end-to-end coverage that:
- Provisions each initial Azure integration.
- Starts a representative Spring Boot application locally.
- Verifies passwordless access using `DefaultAzureCredential`.
- Deploys the same application to Azure Container Apps.
- Verifies passwordless access using managed identity.
- Switches azd environments without changing application files.
- Document supported mappings, required Spring dependencies, local launch methods, credential behavior, configuration precedence, environment switching, override behavior, and known limitations in `cli/azd/extensions/azure.springboot/README.md`.
- Link this issue as blocked by [#9771](https://github.com/Azure/azure-dev/issues/9771), the Spring Boot project detection issue, the project translation issue, the composable Azure resource micro-templates issue, and the Azure Container Apps deployment issue.

## Boundaries

- Do not add Spring-specific commands or verbs.
- Do not add an `azd spring` command namespace.
- Do not add extension-specific run, debug, environment, or configuration commands.
- Do not modify azd core behavior or the core environment model.
- Do not add Spring-specific configuration rules to shared azd packages.
- Do not provision PostgreSQL, Service Bus, Storage, Key Vault, or other Azure resources in this issue.
- Do not modify `pom.xml`, Gradle build files, Java source, Spring configuration, or IDE project files.
- Do not automatically add Spring Cloud Azure dependencies.
- Do not generate `.env` files, shell scripts, or IDE launch configurations containing credentials.
- Do not generate connection strings, passwords, access keys, or other long-lived credentials.
- Do not write secrets into `azure.yaml`, azd environment files, application files, command output, logs, or telemetry.
- Do not automatically install or configure developer credentials.
- Do not grant broader Azure roles than the application or developer requires.
- Do not replace explicit user configuration without reporting the conflict.
- Do not introduce separate local and deployed configuration models.
- Do not require Docker or a local Azure service emulator.
- Do not add configuration mappings for services outside the initial supported set.
- Do not target Azure Spring Apps.
- If the extension framework cannot expose mapped configuration 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, then review the component input and output mapping capability from #9771 and the linked Spring Boot detection and translation work. Add the requested fixtures, table-driven tests, and end-to-end coverage for the supported Azure integrations, overrides, environments, authentication, and failures. Done means documented, deterministic mappings work locally and in Container Apps without secrets or application-file changes.

Written by the indexing model from the issue text.