Validate DistMuon parameter assignments before optimizer construction

[weifengpy]

A DistMuon selection regex can match some parameters while silently leaving others with compute layouts assigned to AdamW. The existing parameter-coverage check accepts that configuration because every parameter still has an optimizer.

Require every locally trainable parameter with a DistMuon compute layout to be assigned to DistMuon. Otherwise, raise ValueError naming the parameter and its assignment before constructing optimizers for that model part. Also catch mapped parameters omitted from every group, including when no DistMuon group exists. Canonicalize checkpoint-wrapped names and ignore frozen parameters and entries for other pipeline stages.

The optimizer container collects assignments and dispatches registered validators; the DistMuon-specific rule lives beside DistMuon. Keep existing string identifiers, taking DistMuon's identifier from DistMuon.__name__.

Stacked on #4811 to review the optimizer-container validation separately from Kimi's parameter selection and Shard(0) compute changes.

Validation:

• All 23 existing optimizer parameter-group tests pass on the parent and this change. No test files are modified.
• Standalone checks reject the old w[123] regex, metadata with only AdamW groups, and mapped unassigned parameters before optimizer construction. Wrapped valid assignments and frozen/off-stage entries are accepted.
• Ten seed-42 deterministic CPU steps with mixed Adam/AdamW match the parent bitwise for loss, gradient norm, parameters, and optimizer state.
• A previous eight-GPU deterministic C4 comparison of the valid Muon configuration with and without this startup validation matched all 10 full-precision training losses, gradient norms, and seven held-out losses.
• Full pre-commit reports the same 30 existing Pyrefly errors; all other hooks pass. Focused type checks pass.