[FEATURE] Cache-stable placement for hook context, and condensing built-in tool output from hooks

Problem

Plugins that give Claude Code precomputed knowledge about a repository (via SessionStart / UserPromptSubmit
additionalContext) pay for it at the most expensive rate and can't reduce what the agent re-reads. We measured this
while building a context plugin and benchmarking it on SWE-QA (48 questions, Sonnet, read-only tools, same commit):

• The SessionStart context is identical for every session in a repository, but it is written to the prompt cache

again in each new session. With ~3.3k tokens of hook context, the first request of a session wrote ~7.9k cache tokens
vs ~4.6k without the plugin; per-prompt context is likewise written, then re-read on every later turn.

• The 13.4k-token system prompt + tool prefix is cached across sessions; hook context, sitting after it, never is.
• Hooks can rewrite MCP tool output (updatedMCPToolOutput) but not built-in tool output, so a plugin cannot condense

a large Grep/Read result into the few spans that matter.

Net effect in our runs: the hooks cut agent turns per question from 5.2 to 3.8 at the same judged score, but total cost
stayed flat (0.94x answers per budget), because the context the plugin adds is billed as cache writes.

Proposed

1. A way for a SessionStart hook to mark its additionalContext as stable (e.g. "cacheable": true), placed so it

shares the cached prefix across sessions in the same project, like the system prompt does.

1. Let PostToolUse hooks replace or condense built-in tool output (Grep, Read, Glob), the same way

updatedMCPToolOutput works for MCP tools, with the original available to the user in the transcript.

Why it matters

Coding-plan users hit session and weekly limits mostly on re-reading code. With (1) and (2), context plugins could
lower frontier usage instead of shifting it. Data, harness and raw results: https://github.com/Spearmintai/mintocode
(see bench/ and the README section "Why the hooks save less").