feat(mla): serve a block drafter from the CuteDSL MLA backend

[nperrin-fr]

DSpark proposes a whole block in one decode forward, so the attention backend must record spec_num_tokens rows per request and re-derive their lengths on every replay. This backend already named the buffer the drafter reaches for (draft_seq_lens_attr) but allocated one row per request and never implemented the hook, so a DSpark run with --drafter-attention-backend tokenspeed_mla died at startup on a missing fill_block_decode_seq_lens.

Each request now expands into spec_num_tokens single-query rows that share the block-end length, which is how the other backends spell it: the kernel takes each row's mask from its own cache length, so equal lengths let every block query attend over the whole block including the positions after it. The page ids repeat across a request's rows and the lengths are written inside the captured graph from the live draft length.

The three GB300 DSpark gates move onto it. They had inherited mla from the AMD gate they were modelled on, where it is the only MLA backend there is; on NVIDIA that costs the draft its split-KV, and the five-layer draft then spends more per layer than the target's tuned kernel does. The AMD gates keep mla, which is the portable spelling.

Measured on GB200 with a four-node TP16 serve, decode goes from 324.2 tok/s to 450.8 tok/s, against 436.9 for trtllm_mla. Accepted tokens per round are unchanged from the mla baseline (6.905/5.479 against 6.905/5.453), so the block keeps its non-causal semantics rather than trading draft quality for speed.

The tests cover what would silently change what a block query attends to, and one of them spies on the decode call: the helper-level cases all pass even when the expansion never reaches the kernel, because reshaping the block back onto the query axis restores exactly the causal order the draft must not have.

Summary

Test Plan