feat(fv-ml1): rebalance GPUs 0/1 by usage; contexts to published maximums; gen-small default output cap

Layout: GPU 0 = cyberprev (KV 16 -> 15 GiB, 1.29x), erp-seat (moved from
GPU 1, KV 8.49 -> 5.5 GiB, 1.32x), voices (ctx 8,192 -> 40,960, its native
maximum, KV 6 GiB, 1.07x), coder (moved from GPU 1, ctx 16,384 -> 32,768,
the card maximum, 2.35x), parakeet-nemo. GPU 1 = gen-small (moved from
GPU 0, 5.5 GiB, 1.76x), meromero-rp (22 GiB, 1.32x), intern-decision.

Sizing rule: KV >= 1.25x max context rounded up to 0.5 GiB, checked against
7 days of LiteLLM traffic and the engines' own KV-usage logs. Each card keeps
spare memory for its bursty tenant (parakeet's cap on GPU 0, intern-decision's
32k call on GPU 1). YaRN extensions are not enabled: they do not fit, and the
Qwen cards warn static YaRN degrades short prompts.

gen-small gets --override-generation-config max_new_tokens 32768. It applies
only to requests that omit max_tokens (vLLM get_max_tokens) and answers 9
runaway ~260k-token replies in 7 days; the longest normal reply was 6,357.

Applied with playbooks/fv-ml1-rebalance-20261005.yaml (boot-check guard and
health/KV verification per seat); all nine seats healthy, gateway smoke
tests pass.

stacks/vllm/README.md

@@ -16,7 +16,7 @@ model on the box, currently three services:
 
 **Server:** ana-ml2
 **Ports:** `8001` (embed), `8002` (rerank), `8003` (reward) — all configurable via `.env`
-**GPU:** all three services share GPU 1 by default (configurable)
+**GPU:** only `vllm-coder` is live in this stack; since 2026-10-05 it runs on GPU 0 (`CODER_GPU_ID`) at the card-published maximum context of 32,768 (KV pinned 77,056 tokens, 2.35×). The embed/rerank/reward services here are retired
 
 ## Why one process per service