fix: Respect PipelineTrainer max_batch_size

[vivekkalyan]

Goal

Make PipelineTrainer.max_batch_size actually do what it says.

Today ART exposes max_batch_size, but _collect_batch() keeps draining the queue after it has already reached the configured cap. That makes the knob misleading and causes the trainer to train on oversized batches.

Direction

Keep this PR very small:

• prove the current behavior is wrong with a focused regression test
• fix only _collect_batch()
• do not change stale-drop behavior, zero-variance handling, or any broader scheduling policy

What Changed

• added a regression test that queues three valid groups with max_batch_size=2 and proves collection should happen across two batches, not one oversized batch
• changed _collect_batch() so the opportunistic get_nowait() drain loop stops once len(batch) == self.max_batch_size
• verified that the next _collect_batch() call returns the remaining group and then sees the sentinel normally

Why This Shape

The bug is not in the initial blocking wait for min_batch_size. It is in the follow-up drain loop, which ignored max_batch_size entirely.

So the fix stays exactly there. No queue rewrite, no new scheduler knobs, no policy changes.

Testing

Sky CPU unit run

• ssh art-pipeline-batching-tests 'cd ~/sky_workdir && ~/.local/bin/uv run pytest tests/unit/test_pipeline_trainer_batching.py tests/unit/test_pipeline_trainer_metrics.py -q'
• result: 2 passed, 8 warnings in 6.33s

Notes

• This PR is stacked on top of PR feat: Support PipelineTrainer with dedicated LocalBackend #621.
• Follow-up scheduling work can build on this once batch collection semantics are correct.