[Bug] Batch: validate scheduled jobs concurrently

[scarlet25151]

Pull Request Description

Batch job admission currently runs inside the scheduling loop before the job is registered in the execution pool. A slow validation therefore blocks later jobs even when pool_size has available capacity.

This change moves admission into the tracked per-job task so that:

• independent jobs can validate concurrently;
• pool_size bounds the full admission and execution lifecycle;
• declined or failed admissions release their pool slot without blocking the scheduler;
• duplicate active job IDs are skipped instead of overwriting tracked tasks.

The concurrency regression test blocks four admissions simultaneously with pool_size=4 and verifies that all four start before execution is released, matching the multi-job scheduling scenario shown in the PR discussion.

Related Issues

N/A

Testing

• poetry run pytest -q tests/batch/test_scheduler.py tests/batch/test_batch_manager.py tests/batch/job_driver/test_deployment_driver.py (70 passed)
• poetry run pytest -q tests/batch/test_e2e_openai_batch_api.py -k "respects_default_job_pool_size or second_job_does_not_stay_validating_when_pool_has_capacity" (2 passed)
• poetry run ruff check .
• poetry run ruff format --check .
• poetry run mypy aibrix/batch/batch_scheduler.py
• poetry run pytest -q tests (1040 passed, 25 skipped, 1 xfailed)

[gemini-code-assist]

Code Review

This pull request refactors the BatchScheduler to decouple job scheduling from job admission, allowing the admission process to run concurrently within the execution pool rather than blocking the main scheduling loop. Tests have been updated to reflect this concurrent behavior. The feedback suggests adding a check to ensure a job is not already being executed or admitted before spawning a new task, which prevents potential duplicate executions and untracked tasks.

[Jeffwan]

did we encounter any issues recently

[scarlet25151]

@Jeffwan this is regarding to the scheduling part,

in the current implementation even we increase the provision concurrency, the scheduling is sequentially and one job at a time, which will cause a long waiting time. this pr fix the issue.