feat: add response caching to avoid redundant Claude API calls #521

Inspiration

ZeroClaw's response_cache.rs maintains a separate SQLite database that caches LLM responses keyed by SHA-256(model + system_prompt + user_prompt). Configurable TTL (default 1 hour), max entries (default 10,000), and hit tracking.

Proposal

Add response caching for Claude CLI invocations in Kōan:

Cache key: hash of (provider + model + system_prompt_hash + user_prompt_hash)
Storage: JSON file or SQLite in instance/cache/responses.db
TTL: Configurable (default 30 minutes for chat, 4 hours for contemplative prompts)

Where it applies:

• awake.py chat responses — identical questions from Telegram get cached replies
• contemplative_runner.py — avoid re-running identical reflection prompts
• claudemd_refresh.py — cache CLAUDE.md generation for unchanged repos
• format_and_send in notify.py — cache Telegram message formatting

Where it should NOT apply:

• Mission execution (always unique context)
• PR review/rebase operations (code-dependent)

Pros

• Significant token savings on repeated chat patterns ("what's your status?", "list projects")
• Reduces Claude API latency for cached responses
• Simple implementation — hash-based lookup
• Configurable per-use-case TTL

Cons

• Cache invalidation is the hard problem — stale responses for dynamic questions
• Storage management adds complexity
• Risk of serving outdated information (e.g., cached status when state has changed)
• Limited applicability — most Kōan operations are unique (missions, PRs)

Complexity

Medium — ~250 lines for cache module + integration at specific callsites

🤖 Created by Kōan — inspired by ZeroClaw's src/memory/response_cache.rs