feat(local): MoE/VRAM offloading helper + local turbo-cache docs

[QodeXcli]

Why

The inference-engine gap the user named: running large MoE coders (Qwen3-Coder-MoE, DeepSeek-MoE) on limited VRAM, plus a local "turbo cache." QodeX already forwards providers.ollama.options verbatim — so num_gpu (layers on GPU, the rest on CPU) Just Works — but it was undocumented guesswork. This makes it usable.

What

• src/llm/offload.ts (PURE) — suggestGpuLayers({ modelSizeGB, vramBudgetGB, totalLayers, reserveGB? }) → a sensible num_gpu, clamped [0, total]. E.g. a 48 GB MoE on a 12 GB GPU → keep ~14/64 layers on GPU. describeOffload() renders a one-line summary for qodex setup / docs.
• Wider options typing — number → number | string | boolean (config + Ollama provider), so any llama.cpp/Ollama runtime flag passes through, not just numeric ones.
• README recipe — "Large (MoE) models on limited VRAM + local turbo-cache." Documents that local speed comes from two things working together:
  1. keep_alive keeps the model + its KV cache warm (no cold reload), and
  2. QodeX's byte-stable prompt prefix (the perf(cache): hierarchical prompt cache — stop re-billing the conversation prefix #44–perf(cache): fold stable guidance into the cached core #48 hierarchical-cache work) means the engine's KV prefix cache hits instead of re-prefilling the whole context each turn — the local counterpart to Anthropic prompt caching.

Honest scope

The actual offloading is done by the local engine (Ollama/llama.cpp); QodeX's job is to expose, compute, and document the knobs — which is what this does. Auto-detecting VRAM/model-layers to set num_gpu automatically is a future qodex setup step; suggestGpuLayers is the pure core it would call.

Tests

+6 (full fit, partial offload, cpu-only fallback, clamping, custom reserve, summary strings). Full suite 1345 green, tsc clean.