Add Spring Boot observability for Azure Container Apps

Add Spring Boot-aware observability to the `azure.springboot` extension. Applications deployed to Azure Container Apps should expose useful application, JVM, and health information through Azure Monitor without requiring developers to manually configure the monitoring stack.

The extension should use Spring Boot Actuator, Micrometer, OpenTelemetry, and the monitoring capabilities already available in Azure Container Apps where the application supports them. It should preserve existing application instrumentation and provide secure, useful defaults without modifying application source or build files.

We need to:

- Implement all Spring Boot-specific observability behavior in `cli/azd/extensions/azure.springboot/`.
- Detect existing use of:
- Spring Boot Actuator
- Micrometer
- OpenTelemetry
- Application Insights
- Other supported Java monitoring agents
- Configure Azure Container Apps logging and monitoring based on the capabilities already present in the application.
- Collect standard Container Apps platform logs and metrics.
- Collect JVM metrics where supported by Azure Container Apps.
- Surface Spring Boot health information through configured Actuator endpoints.
- Configure readiness, liveness, and startup probes consistently with the deployment implementation.
- Send application logs to standard output and standard error.
- Preserve structured logging when the application already emits it.
- Correlate application telemetry with the deployed azd service without collecting application or customer content.
- Reuse existing OpenTelemetry or Application Insights configuration rather than adding duplicate instrumentation.
- Detect conflicting or duplicate Java agents and fail with actionable guidance when they cannot safely run together.
- Allow explicit project configuration to enable, disable, or override supported observability settings.
- Preserve explicit application configuration over inferred settings.
- Explain which observability capabilities were detected, enabled, preserved, or skipped.
- Keep monitoring configuration deterministic for the same project and extension version.
- Ensure telemetry endpoints and credentials are not exposed through command output or committed project files.
- Add fixtures and table-driven tests covering:
- Actuator-only applications
- Micrometer applications
- OpenTelemetry-instrumented applications
- Application Insights-instrumented applications
- Applications with no existing instrumentation
- Conflicting Java agents
- Custom management ports and context paths
- Add end-to-end coverage proving that a deployed application produces:
- Application logs
- Container platform metrics
- JVM metrics
- Health status
- Distributed traces when supported by the application
- Verify that observability remains functional after `azd deploy` and repeated `azd up` operations.
- Document the collected signals, required dependencies, generated Azure resources, configuration, privacy behavior, and known limitations 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 validation issues.

## Boundaries

- Do not add Spring-specific commands or verbs.
- Do not add an `azd spring` command namespace.
- Do not add extension-specific log, monitor, trace, or dashboard commands.
- Do not modify azd core behavior.
- Do not add Spring-specific observability behavior to the built-in Container Apps service target.
- Do not modify Maven or Gradle build files, Java source, Spring configuration, or existing logging configuration.
- Do not automatically add Actuator, Micrometer, OpenTelemetry, or Application Insights dependencies.
- Do not replace or disable existing application instrumentation without explicit configuration.
- Do not install multiple Java agents that provide overlapping instrumentation.
- Do not collect request or response bodies, log contents, configuration values, resource names, endpoints, project names, or other customer content in extension telemetry.
- Do not require a third-party observability service.
- Do not add App Service, AKS, Azure Functions, Azure Red Hat OpenShift, or VM observability behavior.
- Do not target Azure Spring Apps.
- If the extension framework cannot configure observability 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 first review the extension framework, deployment dependencies, and the existing README. Resolve the blocked deployment, detection, translation, configuration, and validation work before defining the observability design. Done requires fixtures and table-driven tests, end-to-end coverage after azd deploy and repeated azd up, and documentation in cli/azd/extensions/azure.springboot/README.md.

Written by the indexing model from the issue text.