Deploy Spring Batch applications as Azure Container Apps jobs

Add Spring Batch support to the `azure.springboot` extension. Spring Boot applications built around batch processing should deploy as Azure Container Apps jobs rather than being treated as long-running HTTP services.

The extension should identify supported Spring Batch applications from the existing project model and configure an appropriate manual, scheduled, or event-driven job through the standard `azd provision`, `azd deploy`, and `azd up` workflows. Explicit project configuration must remain authoritative when the extension cannot safely infer how or when a job should run.

We need to:

- Implement all Spring Batch-specific behavior in `cli/azd/extensions/azure.springboot/`.
- Detect Spring Batch applications from Maven and Gradle dependencies and configuration.
- Distinguish batch-only applications from applications that also expose an HTTP service.
- Represent batch applications through the existing Spring Boot project model rather than introducing a separate application model.
- Deploy batch-only applications as Azure Container Apps jobs.
- Support:
- Manual jobs
- Scheduled jobs
- Event-driven jobs when the trigger can be mapped to a supported KEDA scaler
- Require explicit configuration when the execution model cannot be safely inferred.
- Preserve the application’s existing Maven or Gradle build and executable JAR packaging.
- Use the project wrapper when present and an installed build tool otherwise.
- Configure the job command, arguments, environment, CPU, memory, timeout, retry limit, and parallelism.
- Allow explicit project configuration to override all supported job settings.
- Map Spring Batch job parameters from non-secret azd environment values.
- Pass secrets through supported Azure secret references without writing them to project files or command output.
- Apply the extension’s existing configuration mappings for databases, storage, messaging, Key Vault, and other supported resources.
- Use managed identity and passwordless access for Azure resources.
- Configure scheduled jobs from an explicit cron expression.
- Configure event-driven jobs only for supported Azure services and scaler metadata.
- Validate that scheduled and event-driven jobs cannot overlap unexpectedly when overlapping execution would be unsafe.
- Detect applications that require persistent job metadata and ensure a supported database integration is configured.
- Explain the selected execution model, trigger, command, resource sizing, retry policy, and configuration sources before provisioning.
- Surface job provisioning and deployment status through the normal azd workflow output.
- Produce deterministic infrastructure and deployment configuration for the same project and extension version.
- Add fixtures and table-driven tests covering:
- Batch-only applications
- Applications containing both web and batch behavior
- Manual jobs
- Scheduled jobs
- Event-driven jobs
- Persistent job repositories
- Missing trigger configuration
- Invalid cron expressions
- Unsupported KEDA scalers
- Retry and timeout configuration
- Add end-to-end coverage proving that representative Spring Batch applications can be provisioned, deployed, and executed through standard azd workflows.
- Verify that repeated `azd up` operations are idempotent.
- Verify that `azd deploy` updates the job application without unnecessarily reprovisioning infrastructure.
- Document supported Spring Batch versions, execution models, triggers, configuration, scaling behavior, and known limitations in `cli/azd/extensions/azure.springboot/README.md`.
- Link this issue as blocked by the Spring Boot project detection, project translation, Azure Container Apps deployment, configuration mapping, validation, Maven, and Gradle issues.

## Boundaries

- Do not add Spring-specific commands or verbs.
- Do not add an `azd spring` command namespace.
- Do not add extension-specific run, schedule, or job commands.
- Do not modify azd core behavior.
- Do not treat every application containing a Spring Batch dependency as a batch-only application.
- Do not silently choose a schedule or event trigger.
- Do not convert an HTTP application into a Container Apps job.
- Do not modify Maven or Gradle build files, Java source, Spring configuration, or batch definitions.
- Do not add or replace Spring Batch dependencies.
- Do not provision unsupported trigger resources.
- Do not create a database solely because Spring Batch can use a persistent job repository.
- Do not generate passwords, connection strings, access keys, or other long-lived credentials.
- Do not add App Service, AKS, Azure Functions, Azure Red Hat OpenShift, or VM job support.
- Do not target Azure Spring Apps.
- If the extension framework cannot deploy jobs 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 existing Spring Boot project model, configuration mappings, deployment entry points, and README. Review the linked detection, translation, deployment, validation, Maven, and Gradle work before running the extension's existing tests. Done means batch-only applications support the specified job modes through azd workflows with fixtures, table-driven and end-to-end coverage, idempotent provisioning, and documented limitations.

Written by the indexing model from the issue text.