Put the vLLM-style continuous-batching scheduler steps in correct order for one iteration

**Continuous batching** is how modern LLM servers keep the GPU busy. Instead of waiting for a whole batch of requests to finish, the scheduler rebuilds the active batch every single decode step. Requests can join and leave mid-flight. Each iteration follows a fixed routine. First, the scheduler reaps any request that finished in the previous step, because it hit an end-of-sequence token, a stop string, or its max token limit. Freeing those requests releases their KV cache blocks back to the pool. Second, it computes the budget: how many KV blocks are now free given GPU memory and any reservations. Third, it admits waiting requests up to that budget, running prefill for the newcomers so their prompts are cached. Fourth, if admission over-committed and memory pressure remains, it preempts the lowest-priority running requests, swapping their cache to CPU or marking them for recompute later. Finally, it runs one batched decode step, advancing every active request by exactly one token. Then the loop repeats.

**Continuous batching** schedules at the token level, not the request level. The scheduler runs a tight loop, and each iteration follows a strict order so that resources are freed before they are handed out. The order is: reap, budget, admit, preempt, decode. First, reap requests that finished in the previous step and free their KV blocks. Second, compute the available KV-block budget from current GPU memory. Third, admit waiting requests up to that budget, doing prefill or chunked prefill for newcomers. Fourth, if pressure remains after admission, preempt the lowest-priority running requests by swapping their cache to CPU or scheduling recompute. Fifth, run one batched decode step that advances every active request by a single token. The ordering logic is a classic memory-manager pattern. You must free before you can budget. You must budget before you can admit. Preemption is a fallback that only fires when admission over-committed. The decode step is last because the scheduler wants the densest safe batch before it spends the expensive forward pass.