fix: context readout collapses to the KV-cache delta, then jumps ~4x when the task selector moves

[plombeer31]

The bug

With a local llama-server model on a warm KV cache, the composer's context chip shows a fraction of the real occupied context. Open the context panel and move the task selector to any value other than the current cap (e.g. 22 while only 3–4 tasks exist) and the occupied figure suddenly leaps ~4x — even though the extra tasks don't exist and nothing about the prompt changed.

Root cause

After every completion the TUI overwrites contextUsage.tokens with timing.promptTokens (llm_completed in agent-event-reducer.ts). For llama-server that value comes from timings.prompt_n / tokens_evaluated — which counts only the tokens evaluated on this request. The prefix reused from the KV cache is reported separately as tokens_cached and was dropped. So the "measured" readout was the cache delta, not the prompt.

The task selector's projection (usageAtPairs) recomputes the total from the full-prompt estimator sections. The moment the selector leaves the measured cap, the panel switches from the understated figure to the honest one — that's the "×4 jump". The projection itself is correct (it clamps to the tasks that actually exist); the measurement it was compared against was wrong.

Fix

normaliseCompletionResponse in llama-server-client.ts now reports prompt_n + tokens_cached as timing.promptTokens. That matches what every consumer already assumes — each one falls back to prompt.tokens.total (a full-prompt figure), and the TUI shows it as occupied context. Cloud adapters (OpenAI-compatible, claude/codex CLI) already include cached tokens in their prompt counts and are untouched; cacheHitTokens is unchanged.

Tests

• warm-cache case: prompt_n: 40 + tokens_cached: 30 → promptTokens: 70
• cold-cache case: no tokens_cached → promptTokens: 40, cacheHitTokens: 0
• npx vitest run src/llm (56 files, 597 tests) and tsc --noEmit clean