fix(peft): correct dense MultiLoRALinear on replicated base linears

[yushengsu-thu]

Why

A GLM-5.2_5layer multi-LoRA e2e smoke (the first MLA model through the multi-LoRA path) crashed in the first training forward. The dense MultiLoRALinear mishandles replicated base linears — TELinear parallel_mode='duplicated', i.e. the MLA q/kv down-projections of GLM-5 / DeepSeek-style models. Qwen3-style models never reach these paths (all their LoRA targets are TP-parallel linears), which is why the existing e2e coverage missed them.

This was found on #23's branch and pushed there as 592f5e27, but #23 was merged at f15719c1 without it — this PR is that same commit cherry-picked onto the current bridge tip.

Two defects, both specific to replicated bases

1. Per-slot token spans covered the full micro-batch, but a replicated base under sequence parallelism consumes the SP shard directly (TE stores parallel_mode=None for duplicated linears, so the adapter attribute derivation disables the SP gather). The grouped GEMM's offsets then exceed the row count — an out-of-bounds read surfacing as CUDA error: device-side assert triggered, not a shape error. The spans are now intersected with this rank's contiguous token window (_narrow_token_counts_to_window, the same invariant the MoE slot routing uses for its SP narrow). The host-side total is cached once per micro-batch in set_tokens_per_adapter_slot, so the forward needs no device sync.

2. _gather_output keyed only on input_is_parallel, leaving the adapter output as a [tokens, out/tp] shard while a replicated base produces the full [tokens, out]. It now mirrors ParallelLinearAdapter's lin_out_gather_output: gather for row-parallel and replicated bases.

Deliberately unchanged: the TP collective between the two grouped GEMMs stays unconditional. ParallelLinearAdapter shards A on the rank axis whenever input_is_parallel=False — replicated bases included — so the mid all-gather is required there too (gating it on base_linear_is_parallel was tried and breaks GEMM2 with a contraction mismatch).

Testing

• 4 new CPU tests for the window-narrowing math (slot-boundary-spanning windows, identity, single-slot, many-small-slots); the three multi-LoRA test files pass 74/74 on an H200 devbox.
• GLM-5.2_5layer multi-LoRA e2e (TP=EP=4, ETP=1, SP, thd/tilelang DSA, dp-attention rollout, adapter rank 16 < slot max 32): with this fix (plus [sglang-miles] Allow load_lora_adapter_from_distributed under dp attention sgl-project/sglang#32421 on the serving side) the run completes 3 training steps end-to-end — per-step distributed adapter upserts to both dp-attention engines, (tp, pp, ep) checkpoint shards at the realized coordinates — executed under CUDA_LAUNCH_BLOCKING=1 so no async assert hides.
• Without the fix, the identical run dies in the first wrapped MLA down-projection (torch._grouped_mm device-side assert), reproduced and localized with CUDA_LAUNCH_BLOCKING=1.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.