#5817: fix: strip old images during compaction to prevent 413 session bloat

## Problem Sessions with heavy screenshot usage (browser automation, camera snaps, image reads) accumulate base64 image data in the JSONL transcript. This can cause **413 Request Entity Too Large** errors when the total payload exceeds API limits, making sessions completely unusable. ### Real-world example: - Session file size: 5.33MB - Total images: 28 screenshots - Image data: 3.52MB (88% of session!) - Result: Every API call failed with 413 ## Solution Add image stripping to the compaction safeguard in `compaction-safeguard.ts`: 1. Before summarization, count all images in messages to be compacted 2. Keep images from the **3 most recent messages** that have them (preserves recent visual context) 3. Replace older images with lightweight text placeholders: ``` [Image omitted during compaction: image/jpeg, ~150KB] ``` ## Results Tested on the bloated session: - **Before:** 28 images, 3.52MB image data - **After:** 25 images stripped, 3.23MB saved, 3 recent images kept (0.29MB) - Session reduced from 5.33MB to ~2.1MB — well under API limits ## Changes - Added image detection and counting functions - Added `stripOldImagesFromMessages()` to replace old images with placeholders - Integrated into `session_before_compact` handler - Exported functions via `__testing` for unit testing ## Testing - [x] Build passes (`pnpm run build`) - [x] Unit tests on synthetic messages (5 images → 2 stripped, 3 kept) - [x] Real session test (28 images → 25 stripped, 3 kept) - [x] Placeholders correctly inserted with size info <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This change adds a pre-summarization safeguard in `src/agents/pi-extensions/compaction-safeguard.ts` to reduce session payload size by replacing older base64 image content blocks with lightweight text placeholders, keeping images only in the N most recent image-bearing messages. It also exports the new helpers via `__testing` for unit coverage. This fits into the existing compaction flow by mutating `messagesToSummarize` right before token budgeting and `summarizeInStages()`, aiming to prevent 413 Request Entity Too Large errors caused by screenshot-heavy transcripts. <h3>Confidence Score: 3/5</h3> - Reasonably safe to merge, but split-turn image handling should be checked to ensure 413 prevention is effective. - Core logic is localized and side-effect limited (replacing image blocks with text placeholders), but currently only applies stripping to `messagesToSummarize` while counting images across both `messagesToSummarize` and `turnPrefixMessages`; in split turns this can leave large images unstripped and undermine the PR’s main goal. - src/agents/pi-extensions/compaction-safeguard.ts <!-- greptile_other_comments_section --> _{(4/5) You can add custom instructions or style guidelines for the agent [here](https://app.greptile.com/review/github)!} **Context used:** - Context from `dashboard` - CLAUDE.md ([source](https://app.greptile.com/review/custom-context?memory=fd949e91-5c3a-4ab5-90a1-cbe184fd6ce8)) - Context from `dashboard` - AGENTS.md ([source](https://app.greptile.com/review/custom-context?memory=0d0c8278-ef8e-4d6c-ab21-f5527e322f13)) <!-- /greptile_comment -->