1bit serve: --parallel, --adaptive, RAG (--embed/--rerank), --mtp-p-min; MMQ-only ROCm build

[bong-water-water-bong]

The rest of the serve work: #41 was merged after its first two commits, so these twelve are rebased onto main.

• --parallel N (llama-server -np, continuous batching). Total tok/s at 16 requests: Qwen3.8-27B 68.0 on ROCm (5.8x one stream), Qwen3-Coder-30B 318.9 on ROCm. Vulkan peaks at 8 (50.9 / 228.2).
• --adaptive [--adaptive-at N]: the engine grows with the load. A Vulkan backend with MTP (N slots, default 1) takes the lone request; a ROCm backend with 16 slots and no MTP batches the rest. They are separate because a server with MTP loaded batches at about two thirds of the throughput whatever each request's draft length (measured; the per-request draft scaling that tried otherwise is gone). Choosing the backend and reserving its slot is one locked step: without that a burst of requests all read "empty" and piled onto one slot (measured, fixed).
• --mtp-p-min P, with the full MTP sweep on Qwen3.8-27B in docs/serve.md: default draft 3 = 35.9 / 28.2 / 28.8 tok/s; --mtp-max 6 --mtp-p-min 0.5 = 42.0 on code (3.4x). On Qwen3-Coder-30B-A3B no draft model beats no drafting.
• RAG: --embed MODEL → /v1/embeddings, --rerank MODEL → /v1/rerank, each on its own Vulkan llama-server. Measured end to end over the engine's docs: embeddings with a top-8 context answered 3/4 (the fourth gave the same fact in other units); the rerankers tried did not help (Qwen3-Reranker scores everything ~1.0 through llama.cpp).
• Lean ROCm build: GGML_CUDA_FORCE_MMQ. hipBLAS returns wrong GEMMs on gfx1151 (sgemm silently returns wrong results on gfx1151 (Radeon 8060S): max rel err 1.7e4, no error raised ROCm/rocm-libraries#11530); MMQ-only measured more accurate at the same speed (Qwen3.8-27B UD-Q4_K_XL KLD 0.0064 vs 0.0094).

Built and run on Strix Halo; --adaptive round 4 (after the race fix) is measuring now and its numbers go into docs/serve.md when done.

🤖 Generated with Claude Code