v2.12.1 — Memory recall reflects settings changes

Fix: agent-memory recall now reflects settings changes immediately.

Fixed

• Memory recall ignored settings changes until the index happened to change. The retrieval cache was keyed only by query + memory-index revision, so editing a recall-affecting setting left already-cached queries returning the old result. Most visibly: enabling the reranker (or changing the relevance gate / rerank knobs) appeared to do nothing — a repeated query kept serving its pre-rerank, fusion-only result until an unrelated memory write bumped the index revision. The cache key now embeds a fingerprint of the recall-affecting settings, so any such change invalidates the affected cached queries at once and the next recall reflects the new configuration. (#118)
• deep and balanced recall could share a cache entry. request.mode is now part of the cache key, so a deep query (which escalates a corrective round and gets a larger evidence budget) is never served a balanced cached result, and vice-versa. (#118)

Internal

• services/retrieval/cache.py: add settings_fingerprint() + _RECALL_AFFECTING_KEYS; cache_key() gains mode and settings_fp (both additive, backward-compatible).
• services/retrieval/orchestrator.py: pass mode + settings fingerprint into the key.
• Capture / curator / retention / approval settings are intentionally excluded from the fingerprint — they don't affect the recall read path, so they don't bust the cache.
• Tests: 35 passed (retrieval core + orchestrator + recall e2e + reranker), ruff clean.

Upgrade notes: none. No config, schema, or API changes. On restart the in-process recall cache is empty as usual; the fix only makes the cache key more specific (more correct misses, never a wrong hit). No model re-download.

Full changelog: v2.12.0...v2.12.1