Follow-up from #503 / #516 (epic #507).

Issue #503 lists "cache wiring for the Session-backed runner (~30 min, same
opt-in pattern)". On inspection the semantics are underspecified, so this was
deliberately deferred from PR #516 rather than guessed at.

The ambiguity

Runners.RaxolAgent (the Stream-based runner) has an opt-in
agent.tracker_cache ({module, config} tuple, key {:tracker, issue.id},
30s TTL) that caches still_active? tracker checks between turn boundaries.

Runners.RaxolAgentSession (the full Raxol.Agent.Session lifecycle runner)
has no per-turn tracker poll — its loop just receives session events until
{:done, _} / {:error, _} / timeout. So "the same opt-in pattern" has no
obvious hook: there's no per-turn tracker query to cache.

To decide before implementing

• What the session-backed runner should cache: the rendered prompt? A
  liveness check (which would require interrupting a running Session
  mid-flight)? Something passed into the Session for the agent's own tool/LLM
  calls?
• The invalidation boundary and TTL.
• Whether this is worth it given the session runner's different execution model.

Acceptance criteria

• a short design note pins the cache key schema + invalidation
• opt-in via config, mirroring tracker_cache shape, no behavior change when unset
• tests cover hit/miss + TTL

References: packages/raxol_symphony/lib/raxol/symphony/runners/raxol_agent_session.ex,
runners/raxol_agent.ex (the tracker_cache pattern to mirror), PR #516.