[LoRA] Preserve DeepSeek-V4 grouped wo_a semantics

[zhoutong-hai]

Problem

DeepSeek-V4 wo_a is a grouped projection: G independent [R, D]
matrices are stored in one flattened column-parallel weight. Each input group
must receive only the LoRA delta from its matching output group.

The generic column-parallel LoRA path instead treats the flattened weight as
one dense projection. That introduces cross-group terms and changes the model
operator. It also hides the base-layer attributes used by the native V4
forward.

CP decode attention TP introduces another layout transition: it slices the
replicated base weights for decode while loaded LoRA buffers remain in the
prefill layout. Silently unwrapping an active adapter there would be incorrect.

Fix

• Unwrap the base wo_a layer for the native BF16, FP8, and GGUF projection.
• Add a backend contract that constructs group-major segmented-GEMM metadata
  for one LoRA A and one LoRA B dispatch.
• Route A with the original adapter index repeated per group, and route B with
  a composite adapter/group index, so only the matching group diagonal is
  materialized.
• Preserve the backend's original segment max_len; group count must not
  change kernel tuning or chunk size.
• Cache grouped metadata once per logical forward and rebuild it on the
  eager-to-CUDA-graph capture transition so all metadata transforms are
  captured safely.
• Initialize constant grouped output offsets during eager warmup and fail
  closed if capture begins before initialization.
• Enable the csgmv and Triton backends, which both honor explicit segmented
  metadata for A and B.
• Reject unsupported backends, incompatible grouped layouts, and active LoRA
  under CP decode attention TP. Inactive wrappers are safely unwrapped and use
  the existing base-weight slice/restore path.

This computes the required diagonal directly. It does not allocate a G x G
intermediate and does not issue a separate A/B kernel pair per group.

The target registration and V4 dimensions are in #36578, which should merge
after this execution support. The matching trainer implementation is
radixark/miles#2771.

Validation

• Four focused CPU contract tests pass, including exact grouped algebra,
  routing/permutation metadata, incompatible layouts, and the CP contract.
• TP=2 H200 kernel qualification passed for both csgmv and Triton with:
  • 8,192-token prefill and 8-token decode;
  • two adapters with nontrivial token routing;
  • four local groups per TP rank;
  • CUDA-graph capture after eager warmup and replay after changing adapter
    routing.
• Production output matched an independently assembled group-major kernel path
  bit-for-bit on both ranks and both backends.
• Maximum absolute error versus the grouped-diagonal PyTorch BF16 reference was
  0.03125 for prefill and 0.015625 for decode.
• The diagonal path avoided 192 MiB/rank of off-diagonal B output at 8,192
  tokens (64 MiB instead of 256 MiB).
• Median production/reference latency ratios, using five samples of 20
  iterations, were:
  • csgmv: 0.999--1.001x prefill, 1.115--1.136x decode;
  • Triton: 1.003x prefill, 1.032--1.090x decode.
• Inactive CP decode TP succeeded; active LoRA failed closed as intended.
• Black and diff checks pass.

GPU qualification also caught two problems in the earlier prototype: repeated
metadata inflated csgmv's max_len from 128 to 512 and exceeded H200 shared
memory, while a later implementation allocated grouped offsets during CUDA
capture. The submitted path preserves max_len and initializes the offsets in
eager warmup.

---

CI States

Latest PR Test (Base): ❌ Run #33131282727
Latest PR Test (Extra): ❌ Run #33131282590
Latest PR Test (AMD ROCm 7.2): ❌ Run #33131282712