Fix block allocation for multi-token decode (speculative decoding)

[brucechanglongxu]

BlockManager.can_append and may_append assumed at most 1 new token per decode step. With speculative decoding (mtp_k > 0), the scheduler generates mtp_k + 1 tokens per step, which can cross multiple block boundaries. The old code under-allocated KV cache blocks.

The old can_append used a boolean expression — (len(seq) % block_size == 1) evaluates to True/False, so it checked for at most 1 free block regardless of how many tokens were about to be generated. Fixed to accept num_new_tokens and compute the exact block deficit.

may_append had a similar issue: needed_blocks = (seq_len + block_size - 1) // block_size only accounted for the current sequence length, not the tokens about to be generated. The elif seq_len % block_size == 0 branch also only updated the hash but never allocated new blocks. Restructured into two phases: (1) register the hash if the last block just became full, (2) allocate blocks for ceil((seq_len + num_new_tokens) / block_size).

On the scheduler side, hoisted num_new_tokens = self.mtp_k + 1 before the can_append loop so the check uses the correct token count. Also initialized num_rejected = 0 before the speculative decoding branch in postprocess to fix an UnboundLocalError on the non-speculative path.

Added 15 new GPU-free unit tests covering multi-token can_append/may_append scenarios (boundary conditions, exact-fit, insufficient blocks) and prefix caching during decode (hash registration, cache reuse by new sequences, multi-step prefix building). All 87 tests pass.

Test plan:

• python -m pytest tests/ --ignore=tests/test_utils.py --ignore=tests/test_envs.py — 87/87 pass
• Speculative decoding inference with mtp_k > 0 and prefix caching enabled needs GPU validation
• Standard (non-speculative) inference should be regression-free