[vasilevklart]

Problem. On #391 and #392, MTP turns off past index_topk, so any prompt over 2048 tokens decodes without drafts. An opencode session's first request is about 12k tokens.

Fix.

• GLM-5.2 (configs/glm52_tp8_longctx_mtp.yaml): a verify step trims its rejected rows (latents and index keys) on the device before the next step plans.
• GLM-5.3 (configs/glm5_next_tp8_longctx_mtp.yaml): no trims are needed. The next step's block overwrites the rejected rows, and every rank's page table moves the same way whatever was accepted. The DSA resource moves a verify block to the rows the device says it holds (DSAManager.move_rows, with KVManager.spare_row as the captured pad), so the model no longer re-addresses the KV plan or holds a view of the sink page. An eager prefill step seeds MTP in one pass over its last rows, not one per request.
• A request's max_tokens is checked against what MTP decode can actually emit: the window, and the cache rows a verify step books a whole block of. Before, it was held to index_topk, so any max_tokens after a prompt past ~2k tokens was a 400 (every Claude Code request).
• Greedy only, as with dense MTP. The trims, like the rest of GLM's MTP plumbing, stay model-local until Draft-verify as an engine resource for every MTP model #1195.

GLM-5.3, 8×H200, TP8, passkey, 256 tokens: decode ms/token	4k	32k	128k
M* with MTP	2.74	2.67	3.38
M* without MTP	4.88	4.92	5.15
vLLM 0.31	5.57	5.54	5.47

M*: e08def948 (10-30); with MTP 1 server × 2 reps, without MTP 2 servers × 2 reps.

Tests.

• test_glm5next_mtp_cpu checks that MTP equals greedy without MTP past index_topk, and each step's host rows at a real geometry. It serves joins, departures at their own max_tokens, a reused slot and a stop token among accepted drafts as greedy, for MTP's own, always-right and half-wrong drafts at k = 1 and 3.
• test_dsa_resource::test_move_rows_writes_and_attends_a_block_at_its_true_rows (its eager and captured addressing, on CPU); the captured attention is test_glm5next_mtp_graph on GPU.
• test_glm52_mtp_engine_cycle::test_mtp_stream_matches_baseline_past_topk_on_paged_dsa does the same for GLM-5.2.
• CPU Core on 3a614c4b8 (11,705 passed) fails no test that Serve GLM chat with roles, tool calls, reasoning and usage #397 (660e86f20) passes, by name; the TP lockstep sim, test/rust and ruff pass.
• GPU, on an H200 at the stack's top with the upper fixes (d877bfde4, job 507): test_glm5next_mtp_graph and test_glm5next_mtp_cpu pass (54, 1 xfail). CPU Core is on torch 2.10, pyproject's floor; the GPU runs on 2.11.

Known limit. A GLM-5.3 verify step books its whole block and the host never takes the rejected rows back, so near the window admission refuses more than plain decode would (test_long_context_mtp_books_at_most_a_block_past_the_rows_it_holds, a strict xfail for the follow-up).

AI assistance (Claude) was used for this PR.