refactor(args): fold --diffusion-model into --hf-checkpoint

[Rockdu]

This PR is stacked on #141.

What

• Delete --diffusion-model. --hf-checkpoint becomes the single model reference, and is now required.
• Point its three readers at the survivor: the sglang-d engine's model_path, LTX's DiT resolution, and resolve_diffusion_model_family.
• Add --diffusion-model-family, so a checkpoint whose path lacks the family name can still name it.
• Point the LTX recipe's --hf-checkpoint at Lightricks/LTX-2.3.

Why

Two flags named the same repo id from opposite ends, and five of the six recipes passed the identical value to both. The field the family lookup matches against has always been called hf_ckpt_name_patterns; miles has only --hf-checkpoint. One value means the engine and the trainer can no longer disagree about which pipeline is being trained.

Two things worth a reviewer's attention:

1. A sentinel, not a read. The three if getattr(args, "diffusion_model", None): guards in miles_validate_args used that flag's non-empty default as an "is this a diffusion run" test, inherited from miles where the attribute does not exist. They are unconditional here — one caller, parse_args, whose parser always registers these arguments. Renaming underneath them would have flipped them off whenever --hf-checkpoint was absent, and silently: no TrainPipelineConfig resolution, no validate_sp_args, and sp_size pinned to 1 so dp_size and the global_batch_size divisibility assertion both came out wrong.

2. Your own weights. One value also means a path lacking ltx/sd3/wan2.2/qwen-image no longer resolves — the normal case for a directory of your own weights, and previously servable by pointing the two flags at different places. That hatch existed only as MILES_DIFFUSION_MODEL_FAMILY, invisible in --help; it is now a flag, with precedence flag > env > name match. --train-pipeline-config-path still covers families that are not registered at all; passing both now raises. miles solves this from the other side — it derives identity from the checkpoint's own config with --model-name as the override — but LTX's official repo ships no model_index.json, so the pipeline-class route cannot serve the one family that needs it most.

Validation

Captured train_args from all six recipes plus the smoke and debug-alignment variants (7 total), before and after. The only differences: --diffusion-model and its duplicate value gone, and the LTX recipe's --hf-checkpoint now carrying Lightricks/LTX-2.3. num_gpus_per_node and the extra_env_vars passed to execute_train are unchanged for all seven, and the --diffusion-model-family commit leaves all seven byte-identical. Family resolution re-checked from --hf-checkpoint for every model the recipes use: LTX-2.3 → ltx, Wan2.2 → wan2_2, SD3.5 → sd3, Qwen-Image → qwen_image. The new flag's six branches were replayed standalone, including both error cases. pre-commit clean; py_compile clean.

Not verified here: pytest and train.py --help need torch/sglang/ray, which this environment lacks — CI covers both. No new tests: the added logic lives in miles_validate_args, reachable only through parse_args, which has no fixture in the repo.