[recipe] fix: make Ministral3 defaults runnable

[yaoyu-33]

What does this PR do?

Makes all six public Ministral3 H100 SFT and PEFT recipe defaults pass Bridge's supported batch-configuration contract.

The shared VLM helpers enable in-batch packing, while these GPU-sized recipes deliberately set micro_batch_size=1. The normal runner therefore rejects each default during runtime configuration because in-batch packing requires a micro-batch greater than one.

This patch disables in-batch packing only in the affected Ministral3 constructors. That preserves their documented GPU counts and memory-sized micro-batch defaults; users can still opt into packing together with an explicit micro-batch greater than one.

User impact

Before this change, invoking any of the six canonical defaults (or their direct compatibility aliases) fails before training begins. The regression test covers the full SFT/PEFT constructor set and asserts the public packing/batch invariant.

Validation

Fail-before on unmodified main:

uv run python -m pytest tests/unit_tests/recipes/test_ministral3_recipes.py -k defaults_validate -q
# 6 failed, 28 deselected

Pass-after with the unchanged regression test:

uv run python -m pytest tests/unit_tests/recipes/test_ministral3_recipes.py -k defaults_validate -q
# 6 passed, 28 deselected

Adjacent coverage:

uv run python -m pytest tests/unit_tests/recipes/test_ministral3_recipes.py -q
# 34 passed

uv run python -m pytest tests/unit_tests/training/test_config.py -k in_batch_packing -q
# 6 passed, 261 deselected

uv run pre-commit run --all-files
# all hooks passed

git diff --check
# passed

Scope is limited to recipe construction and CPU unit coverage. No GPU, convergence, performance, or full-suite validation was run.

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[yaoyu-33]

/ok to test 2883d5a

[claude]

Light review

The change adds enable_in_batch_packing=False to all six Ministral3 H100 recipes (3B/8B/14B x SFT/PEFT) and adds a parametrized test over all recipes. Verified:

• enable_in_batch_packing is a real field on DirectHFSFTDatasetConfig (data/builders/direct_hf_sft.py:91, default False), so this is a safe explicit default, not a phantom field.
• The top-level ministral3_*_config names the test parametrizes over are aliases of the exact h100/ministral3.py functions the diff edits, so the new test does exercise the changed code.

One concern: the new test_each_ministral3_recipe_defaults_validate assertion not cfg.dataset.enable_in_batch_packing or cfg.train.micro_batch_size > 1 is a tautology -- every recipe sets packing to False, so the left side is always True and the right side is never evaluated. The test passes regardless of the recipe values and would not catch a regression where packing is enabled while micro_batch_size stays 1.

Otherwise LGTM -- no logic bugs, typos, or doc drift.

Suggested test cases

• No perf tests impacted.
• tests/unit_tests/recipes/test_ministral3_recipes.py::test_each_ministral3_recipe_defaults_validate (all six recipe params)

[claude]

This assertion is a tautology given the recipes as written: every recipe sets enable_in_batch_packing = False and micro_batch_size = 1, so the left disjunct (not False) is always True and the right operand is never evaluated. The test passes regardless of the recipe values and would not catch a future regression where someone enables packing while leaving micro_batch_size = 1.

Consider asserting the intended invariant more directly, e.g. explicitly checking the current expected defaults, or — if the goal is to guard packing+mbs consistency — parametrizing a case that actually sets enable_in_batch_packing = True so the micro_batch_size > 1 branch is exercised.