Add Spring Boot validation to standard azd workflows

Add Spring Boot-aware validation to the `azure.springboot` extension using the azd validation provider capability. Before azd builds, provisions, or deploys a Spring Boot application, the extension should identify configuration and compatibility problems that would otherwise fail later or produce a broken deployment.

Validation should run as part of the standard `azd provision`, `azd deploy`, and `azd up` workflows. It should explain what is wrong, identify the affected service, and provide a concrete next step. Validation must not modify the application, install tools, or introduce a separate diagnostic command.

We need to:

- Implement all Spring Boot-specific validation in `cli/azd/extensions/azure.springboot/`.
- Register the extension’s validation provider using the existing `azdext` capability.
- Run the appropriate validation before provisioning and deployment.
- Validate each detected Spring Boot service independently.
- Validate that the selected Java version is supported by the configured deployment target.
- Validate that Maven or Gradle is available when the project does not include the corresponding wrapper.
- Validate that checked-in Maven and Gradle wrappers include the files required to run on the current operating system.
- Validate that the expected Maven or Gradle module still exists.
- Validate that the configured build produces the artifact expected by the project model.
- Validate that the detected application port, management port, context path, and health endpoints are compatible with the selected deployment configuration.
- Validate that explicit health-check configuration does not point to an unavailable or inaccessible Actuator endpoint.
- Validate that the selected Azure region supports Azure Container Apps and every managed Spring component required by the project.
- Validate that resource configuration is compatible with the application’s detected Spring and Spring Cloud Azure dependencies.
- Validate that passwordless authentication is supported for each configured Azure integration.
- Validate that the application identity has the role assignments required by each configured integration.
- Validate that explicit application configuration does not conflict with values supplied by azd.
- Validate that a multi-module project has stable and unambiguous service identities.
- Validate that service, layer, input, and output names do not collide.
- Validate that the pinned `azure.springboot` version supports the project model and configuration in use.
- Distinguish errors that must stop the workflow from warnings that the developer can safely review later.
- Deduplicate findings so the same problem is not reported by detection, provisioning, and deployment validation.
- Order findings consistently by service and validation category.
- Use actionable messages that identify:
- What is wrong
- Which service or resource is affected
- What evidence caused the finding
- How the developer can correct it
- Keep validation output consistent in interactive and `--no-prompt` workflows.
- Return structured validation results where supported by the extension API.
- Avoid exposing environment values, credentials, resource identifiers, local paths, or other customer content in telemetry.
- Add fixtures and table-driven tests covering Maven, Gradle, JAR, WAR, multi-module projects, unsupported Java versions, missing wrappers, missing artifacts, invalid ports, unavailable regions, configuration conflicts, and missing role assignments.
- Add integration tests proving that validation runs through standard `azd provision`, `azd deploy`, and `azd up` workflows.
- Verify that blocking findings stop the workflow before Azure resources are changed.
- Verify that warnings do not block the workflow.
- Document validation behavior, supported checks, severity rules, and remediation guidance in `cli/azd/extensions/azure.springboot/README.md`.
- Link this issue as blocked by the `azure.springboot` extension foundation, project detection, project translation, Azure Container Apps deployment, configuration mapping, and managed Spring component issues.

## Boundaries

- Do not add Spring-specific commands or verbs.
- Do not add an `azd spring` command namespace.
- Do not add a `doctor`, `check`, `validate`, or other extension-specific command.
- Do not modify azd core validation behavior.
- Do not add Spring-specific validation rules to shared azd packages.
- Do not modify Maven or Gradle build files, wrapper files, Java source, or Spring configuration.
- Do not install or upgrade Java, Maven, Gradle, Spring Boot, or project dependencies.
- Do not build or run the application when a static validation can answer the question.
- Do not provision, update, or delete Azure resources during validation.
- Do not automatically correct explicit user configuration.
- Do not require live Azure access for validations that can be performed locally.
- Do not treat warnings as errors solely to enforce an opinionated project style.
- Do not validate deployment targets or Azure integrations that the extension does not support.
- Do not target Azure Spring Apps.
- If a required validation cannot be implemented through the existing validation provider, 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 inspect the existing azdext validation-provider capability and standard provision, deploy, and up workflows. Review the extension README and foundation, detection, translation, and deployment dependencies before defining the validation boundaries. Done means fixtures and integration tests cover the listed checks, blocking findings stop workflows before resource changes, warnings do not block, and behavior is documented.

Written by the indexing model from the issue text.