feat: response caching for repeated prompts

[JNK234]

Roadmap priority: B5

Summary

Return a cached reply for an identical prompt + model + parameters combination, instead of re-calling the provider.

Why it matters

BehaviorSpace parameter sweeps repeat prompts heavily — the same system prompt and the same early-tick observations recur across every run in the sweep. Each repeat is currently billed and waited on again. Caching is a direct cost and wall-clock saving for exactly the workflow researchers use most.

Note: mesa-llm has no caching at all (verified — grep for lru_cache|redis|memoize across their package returns zero hits), so this is a differentiator rather than catching up.

What needs to be done

1. Define the cache key: model + provider + full message sequence + temperature + max_tokens + thinking config. Anything affecting output must be in the key.
2. Decide scope and lifetime — in-memory per session, or on-disk across runs (on-disk is what makes sweeps benefit).
3. Opt-in config key (enable_cache), off by default. Caching changes semantics for any model relying on sampling variation, so it must never be silently on.
4. Interaction with temperature > 0 — cache hits eliminate the intended randomness. Either refuse to cache when temperature is non-zero, or make that an explicit modeler choice.
5. Eviction policy and size cap.
6. Optional: report hit/miss counts so the saving is visible.

Open questions

• On-disk cache location — model directory, or a user-level cache dir? Model directory is more portable for sharing a reproducible run.
• Does this overlap enough with record/replay to be one feature? (See B6.) Replay is exact-sequence playback; caching is content-addressed. Related but not identical.