fix(ml): KV-carrying decode cursors — O(T) speculative decode

[ronaldtse]

Replaces the speculative decode implementation's cost model and records what the measurement taught.

The fix. IMFModel.cursor(hidden) — a DecodeCursor carrying KV caches across calls (seed/feed/rewindToLen; plain-graph models recompute behind the same interface). The speculative loop becomes one incremental decoder run per block per model, O(T) total — the first implementation re-prefilled from zero every block (O(T^2), 5.7x slower than plain decode). KV rewind slices per head: [1,H,S,D] memory is not a contiguous prefix, and the naive slice silently corrupted caches (caught by exactness on the tiny fixture).

What the benchmark measured (scripts/bench-speculative.mts, arm64 CPU, warm, 5 golden rows; interscript-ml RESULTS.md 2026-09-12):

• plain 2.1 int8 21.4s · lite int4 75.7s · speculative 155.4s
• int4 CPU kernels (MatMulNBits) lose to int8 — the "small drafter" is the expensive model on CPU
• dynamic-int8 graphs compute activation scales per fed tensor, so single-step vs batched decode framing yields materially different decodes: runtime acceptance 0.4614 vs the probe's 0.9886 (a uniform-framing artifact), and the batched-verifier output lost a word on a canonical row

Positioning consequence (playground tier pulled in interscript.github.io#185): SpeculativeModel is documented as measurement infrastructure on quantized artifacts; output preservation vs translate() holds for fp-class pairs. The e2e asserts decode health and honest stats on the quantized pair; the fixture pair (drafter==verifier) still asserts exact equality.

Full suite 271 passed; the module docstring carries the constraint.