fix(recipe): add library aliases for the colliding GLM-5.2 SFT recipes

[pruprakash]

What does this PR do ?

Fixes the GLM-5.2 verification card's two SFT reproduction commands launching a 131,072-token benchmark job instead of the library configuration their published metrics were measured on, by giving those library recipes a distinct name.

Changelog

• recipes/glm/h100/glm5.py: add glm52_h100_sft_config alias.
• recipes/glm/gb200/glm5.py: add glm52_gb200_sft_config alias.
• recipes/glm/{__init__,h100/__init__,gb200/__init__}.py: export the aliases.
• examples/model_verification_cards/glm5-2/card.yaml: both SFT commands name the alias.
• tests/unit_tests/recipes/test_glm5_recipes.py: 4 parametrized cases over the aliases and the shipped card commands.

Additional Information

• Root cause: both SFT names are exported by megatron.bridge.recipes and megatron.bridge.perf_recipes; load_recipe binds the benchmark definition and the library workloads had no other name.
• Blast radius: card only. Purely additive — the colliding names still resolve to the benchmark recipes.
• Regression? Yes. The SFT leaves were verified 2026-07-22 / 2026-08-04; the collision registry that changed what those names mean landed later. Found while testing docs: add DeepSeek V3 verification card #5583, not caused by it.
• Verification: red-green in nvcr.io/nvidian/nemo:nightly — RED is a collection AttributeError without the aliases and 2 failed with the card unchanged; GREEN is 20 passed. On the patched tree load_recipe returns gbs=32/seq=2048 (H100) and gbs=8/seq=8192 (GB200), matching the card.
• Not included: the other 7 BENCHMARK_RECIPE_PRECEDENCE_COLLISIONS entries still lack a library alias, and validate_card.py still does not check --recipe.

[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.

[claude]

LGTM

Clean, well-motivated fix. The recipe names glm52_sft_416gpu_h100_bf16_config and glm52_sft_192gpu_gb200_bf16_config are in BENCHMARK_RECIPE_PRECEDENCE_COLLISIONS, so a bare --recipe launcher lookup resolves them to the benchmark (perf) definitions rather than the library SFT recipes the verification card intends. Introducing the generic aliases glm52_h100_sft_config and glm52_gb200_sft_config, and pointing the card at them, keeps the intended library workloads selectable.

Verified:

• Both aliases are reachable by the launcher: the top-level glm package all re-exports glm52_gb200_sft_config, and glm.h100 all re-exports glm52_h100_sft_config (the two paths recipe_runner searches).
• The new alias names do not themselves collide with benchmark recipes, so load_recipe falls through to the library lookup.
• Test assertions match the underlying configs (H100: GBS 32 / seq_length 2048; GB200: GBS 8 / seq_length 8192) and the card YAML structure (items.sft.H100/GB200.command).
• Good targeted unit coverage: alias identity, card command wiring, and documented batch shape.

Suggested test cases:

• No perf tests impacted. This PR touches library recipes, the model verification card, and unit tests only; no configs under scripts/performance/ are modified. The added unit tests test_glm52_sft_card_command_names_the_library_alias and test_glm52_sft_alias_keeps_the_documented_batch_shape in tests/unit_tests/recipes/test_glm5_recipes.py are the relevant coverage.

[pruprakash]

/ok to test 32c0ad9