[multi-lora] 1/n - 7, ci: validate LayerWise expert ownership integration

[yushengsu-thu]

ci-megatron-pr: #82

Depends on radixark/Megatron-LM#82 (LayerWise expert ownership) and radixark/Megatron-Bridge#27 (grouped-expert LoRA recompute + expert-DDP routing, merged to @bridge).

What

• docker/Dockerfile: the CUDA image now installs Megatron-Bridge from the bridge branch (which carries the merged Tiny refactor branching in getting dataset samples #27 fixes) instead of a pinned pre-Tiny refactor branching in getting dataset samples #27 SHA. Caveat: buildkit caches this layer on the instruction text, so rebuilds need --no-cache (or a cache-bust) to pick up new bridge commits.
• One image-level 2-GPU contract test (tests/fast-gpu/test_layerwise_expert_dependencies.py, single register_cuda_ci, est 90s, labels=["lora"]): a single torchrun worker asserts the whole dependency chain in one pass —
  1. Bridge Tiny refactor branching in getting dataset samples #27 stamps grouped-expert adapter weights allreduce=False + tensor_model_parallel=True;
  2. Megatron-LM Fix fsdp prob diff computation when tis is disabled #82 routes them into LayerWise's expert-DP ownership domain (dense list empty, each param exactly one owner);
  3. the reported grad norm equals the true L2 norm (no √TP over-count) and the optimizer step succeeds with clipping effective.

Why

Expert-only LoRA on a pre-#27 bridge trains as a silent no-op under full recompute, and pre-#82 LayerWise double-counts TP-duplicated adapter grads (grad_norm = √2 × true, clipping under-scales). This test is the acceptance canary for both pins and the only CI guard that catches a stale-baked bridge image: it fails on a pre-#27 image and passes on the current bridge tip.