Cuda Serve

One GPU **worker thread** runs the continuous-batching loop (admit → prefill → `decodeBatch` → evict); many transport (HTTP) handler threads `submit` requests concurrently and **stream each request's own tokens incrementally** as the worker produces them. This is the threading model proven token-identical to N isolated single-sequence runs by the `dbg_cuda serve` harness (3a); 3b factors it into a reusable engine and adds the per-token streaming registry the HTTP/SSE transport needs.

ADDITIVE: the production single-sequence `decodeStep`/`prefillBatched` path is untouched. The engine REUSES `Scheduler` + `ForwardGemma.decodeBatch` (proven in increments 1+2); the only genuinely-new code here is the cross-thread result registry + the GPU worker loop.

Thread-safety model (identical to the 3a proof): * ALL GPU work (`decodeBatch`, prefill) runs ONLY on the worker thread. The CUDA shim rebinds the context per call (`cuCtxSetCurrent` at every entry), so a single GPU-owning thread needs no extra ceremony. * Cross-thread mutable state = the scheduler `pending` FIFO (handlers append via `enqueue`; worker drains via `admitNext`) + the per-request channel registry. Both are guarded by ONE `mutex`. Slot state (prefill / decode / append / release) and the scratch slices are worker-only and lock-free. * Each sequence's tokens depend only on its own slot KV + position (proven isolated in increment 1), so the nondeterministic admit/interleave ORDER across handler threads cannot change any sequence's output.