feat: 3-block system prompt for cache-efficient LTM injection

[BYK]

Summary

Split LTM injection into two separate system prompt blocks — stable LTM (preferences) and context-bound LTM (gotchas, patterns, architecture) — to improve Anthropic prompt cache hit rates.

System prompt structure

Block 0: Host prompt        — no cache_control (covered by prefix)
Block 1: Stable LTM (prefs) — cache_control: 1h TTL
Block 2: Context-bound LTM  — no cache_control (rides 5m conversation cache)

Cache behavior

• Blocks 0+1 form a stable prefix written once at 2× cost, read at 0.1× for the entire session (and across sessions within 1h)
• Block 2 + messages ride the conversation cache (5m TTL, 1.25× write)
• When context-bound LTM changes (turn 1→2, curation), only block 2 + messages are re-processed; blocks 0+1 remain cache reads
• Stable LTM is pinned for ≥1h even through curation changes — stale preferences are tolerated to preserve the cache prefix investment

Changes

• packages/gateway/src/translate/anthropic.ts: Add stableLtmSystem to AnthropicCacheOptions; buildAnthropicRequest emits 3 system blocks when stableLtmSystem is set. Host prompt no longer gets its own cache breakpoint — the stable LTM block's 1h breakpoint covers the prefix. Falls back to host prompt breakpoint when no stable LTM exists.
• packages/gateway/src/pipeline.ts: Compute preferences separately via stableLtmCache (computed once per session, not invalidated by curation or idle resume). Context-bound LTM uses excludeCategories: ["preference"] to avoid duplicating preferences already in block 1. Layer 4 emergency only refreshes context-bound LTM, keeping stable LTM pinned.
• packages/core/src/ltm.ts: Add excludeCategories to ForSessionOptions — generates AND category NOT IN (...) SQL clause. Mutually exclusive with categories (include wins).
• Tests: 8 new tests for 3-block system prompt behavior in anthropic-caching.test.ts; 2 new tests for excludeCategories in ltm.test.ts.

Cost analysis

Scenario	Before	After
Turn 1→2 (LTM changes)	Re-process all LTM + messages	Only block 2 + messages; blocks 0+1 are cache reads
Curation changes prefs	Full LTM cache bust	Block 1 stays pinned; only block 2 may change
New session within 1h	Host prompt is cache read, LTM is cold	Blocks 0+1 are cache reads from previous session