[PD] Transfer DFlash draft KV separately from DCP target indices

[chromecast56]

PD + DCP + DFlash PR stack (merge bottom-up; each PR is based on main and includes the PRs below it)

1. Fix PD retraction checkpoint boundaries with overlap decoding #39743
2. [Spec] Support DFLASH for Kimi K3 #40794
3. [DCP] Use logical token capacity for PD admission and load reporting #39731
4. Preserve full DFlash draft KV during PD CPU retraction #39749
5. [PD] Transfer DFlash draft KV separately from DCP target indices #40192 ← this PR
6. [PD] Count transferred state bytes per component #40164

Review only the last 3 commits; the earlier commits belong to the PRs below.

---

Motivation

Under DCP the target MLA KV moves as rank-local rows, while a full (non-compact) DFlash draft pool is replicated and indexed by the target allocator's logical token ids. With the same DCP size on prefill and decode, NIXL's send_kvcache appends the draft buffers to the target KV entries and applies the target's rank-local page indices to them, so decode receives the wrong draft rows. The target verifies every drafted token, so the cost is acceptance rate.

Modifications

• DFlashDraftTransfer (new disaggregation/dflash_kv.py) is resolved once per PD queue from the full draft pool that Preserve full DFlash draft KV during PD CPU retraction #39749 registers on the allocator. It applies only under DCP on NIXL. Without DCP the target indices are already logical, and the draft keeps riding the target KV entries (num_draft_entries).
• The draft is sent as its own DFLASH_KV state component, appended last so other components keep their positions when only decode registers a draft. Its buffers are described in target wire-page units, and both sides index them with logical token ids from req_to_token.
• Neither side knows the peer's DCP size when it registers, so a DCP>1 decode registers the draft both ways: among its KV entries, for a DCP=1 prefill's existing relayout plan, and as DFLASH_KV, which a same-DCP prefill sends instead. NIXL registers each buffer once.
• The payload starts at the decode prefix, which already holds its draft KV (same as the SWA payload). It sends only the sliding-window tail when every draft layer is sliding_attention; otherwise it sends the whole suffix.
• Prefill and decode share one payload helper. NIXL rejects prefill/decode attention-TP mismatch for this component when the peer registers. DFLASH already requires pp_size == 1 at startup.
• Compact draft caches and the Mooncake path are unchanged.

Registering the draft both ways on decode is a new transfer shape: a same-DCP prefill sends fewer KV regions than decode registered, as decode-only speculative decoding already does on main. If you'd rather negotiate this at handshake time, I'm happy to restructure.

Tests

test_dflash_logical_transfer.py (5 CPU tests, 11 subtests):

• DFLASH_KV is registered only for a registered full draft under DCP on NIXL; non-DCP deployments keep the existing target-entry path.
• The tail window applies only when every draft layer slides. Reading sliding_window alone would truncate mixed and full-attention drafts, whose configs can still carry it.
• A DCP8 request's payload skips the decode prefix, and NixlKVManager.maybe_send_extra writes the logical rows into the decode draft buffers.
• The window tail starts on a page boundary.
• Prefill and decode layouts agree for P1->D8, P8->D8 and P1->D1: decode has at least prefill's KV regions, prefill's state list is a prefix of decode's, the relayout geometry check passes, and decode registers no buffer twice. P1->D8 failed the region check when decode dropped its draft entries.

---

CI States

Latest PR Test (Base): ⏳ Run #35796399951
Latest PR Test (Extra): ❌ Run #35796399956
Latest PR Test (AMD ROCm 10): ⏳ Run #35796400143

[chromecast56]

/tag-and-rerun-ci

[chromecast56]

Closing. On main, a DCP8 → DCP8 PD transfer already delivers the DFlash draft KV correctly: the DCP draft pool is built with the widened page size (page_size * loc_space_scale, kv_cache_configurator.py:409-415), so one page-index vector addresses the same logical rows in the target and draft pools. A GPU check on Kimi K3 1P1D (prefill TP8 DCP8 → decode TP8 DCP8, DFLASH full draft, NIXL) without this PR gave GSM8K 95.2% and average accept length 4.97, matching DCP1 → DCP1 (95.7% / 4.99). The layout problem this PR worked around only exists on our fork.