speculative: window dspark drafter staging to its trained position range

[thadreber-web]

Overview

draft-dspark stages every context row since the drafter's cache position plus a full draft block in one batch. To make that fit, the server raised the draft context's n_batch to the target n_ctx + block size. Causing two problems:

1. At large -c, the draft context reserves a compute buffer sized for a full-context micro-batch. This is the ~5.9 GB allocation and boot OOM reported in Misc. bug: DSpark drafter inheriting main model's context size #74 (raising draft ctx n_batch 1024 -> 32772).
2. Rows are staged at absolute target positions, but the drafter's trained context is only 4096. Past that, the drafter runs attention/RoPE at positions it never saw in training. Measured on Ternary-Bonsai-27B (Q2_0 target, Q4_1 drafter): acceptance falls from 59% on short prompts to 4.6% at ~28k tokens, making speculation slower than no speculation.

This PR windows the drafter's staging instead:

• The drafter only ever runs at positions [0, window), window = min(drafter n_ctx_train, n_batch). Staged rows are rebased (drafter_pos = abs_pos - pos_base).
• The server now caps the draft context's n_batch at the drafter's n_ctx_train instead of the target n_ctx, which removes the large compute buffer from (1).

No new CLI flags, no API changes. A drafter GGUF without context_length metadata falls back to the batch-size ceiling, i.e. the old behavior.

Measured (ctx 131072, DGX Spark GB10):

• short/moderate context: ~70-78% acceptance, 54-58 tok/s decode
• 60k context: ~69% acceptance, 32 tok/s
• 24k-deep prompt: 1.36x over no-speculation, where the old absolute-position staging measured 0.69x (slower than no speculation)

Additional information

Fixes #74. The failed-decode and failed-crop recovery paths reset the window bookkeeping (pos_base, n_retained) along with the existing cache reset, so a rebase that fails mid-round
cannot leave the drafter cache and the staging buffer out of sync. Buffer head trimming is done lazily in 512-row chunks to keep the erase off the per-round hot path.

Requirements

• I have read and agree with the contributing guidelines
• AI usage disclosure: YES - analysis done by Fable. I supervised and reviewed the implementation and bench marking.