feat: LLM response caching across eval runs

[christso]

Problem

Running the same eval suite repeatedly makes redundant LLM API calls for identical inputs. This wastes cost and time when iterating on evaluator logic.

Proposal

Cache provider responses keyed by hash(provider + model + input + config):

execution:
  cache: true                    # default: false
  cache_path: .agentv/cache     # default location

CLI

agentv run --target my-agent evals/          # uses cache if configured
agentv run --target my-agent evals/ --no-cache  # bypass cache

Rules

• Cache agent/provider responses only (the expensive LLM calls)
• Never cache evaluator results (evaluator logic may change)
• Temperature > 0 not cached by default (non-deterministic)
• Cache is a directory of hashed response files — portable, inspectable

Why No agentv cache Subcommand?

Per design principle #5 (AI-First): minimize commands. rm -rf .agentv/cache clears the cache. No need for a dedicated command.

Design Principles Alignment

• ✅ Lightweight Core — infrastructure concern, intercepts provider layer
• ✅ Non-Breaking Extension — opt-in via config, existing behavior unchanged
• ✅ AI-First — fewer commands, simple mental model

Acceptance Criteria

• Response cache with configurable path
• --no-cache flag
• Cache key based on provider + input + config hash
• Evaluator results never cached
• Documentation

[christso]

Status: Deferred

Maintainer decision: Defer this issue. Benefits are minimal for the current use case — eval runs typically need to test variability across runs, and caching would mask that. The default behavior should always be fresh LLM calls.

This can be revisited later if eval suite sizes grow large enough that cost becomes a significant concern during iterative evaluator development.