Compaction permanently bricks sessions after Word/PPT/image workflows exceed the 5 MB request limit

### Short summary

A long-running session that has processed Word documents, PowerPoint decks, or multiple images can become permanently unusable when automatic compaction serializes retained binary assets and the CAPI request exceeds 5 MB.

### Affected version or release

GitHub Copilot app 1.1.2; bundled Copilot CLI 1.0.73.

### Installation context

GitHub Copilot desktop app on Windows 10.0.26200 x64. The affected workspace was a collection project with one parent session and several coordinated child sessions.

### What happened?

After a long session used document/image tooling, every subsequent prompt failed during automatic compaction with:

```
Error: The request is too large to send through CAPI Responses. Try shortening the conversation or prompt. (5.5 MB request; 5.0 MB limit)
```

Retrying, sending a tiny prompt, or reopening the session did not help because every turn retriggered the same failed compaction. The conversation, plan, worktree, and child sessions still existed on disk, but the parent session was effectively bricked and could not continue through the UI.

This happens repeatedly in workflows involving PPT, Word, screenshots, rendered slides/pages, or Figma/image inspection.

### Steps to reproduce

1. Create a long-lived project session, optionally with coordinated child sessions.
2. Use document/image tools over time to inspect Word documents, PowerPoint decks, rendered pages/slides, or several PNG screenshots.
3. Continue until automatic context compaction runs.
4. Observe the compaction request fail once its serialized payload exceeds CAPI's 5 MB request limit.
5. Send a tiny follow-up prompt or click retry.
6. Observe that the same compaction failure repeats indefinitely and the session cannot recover itself.

### Expected behavior

Binary assets should not be repeatedly embedded in compaction requests. Compaction should reference persisted assets, omit already-processed base64 data, downsample/prune old image payloads, or fall back to a size-based truncation strategy. If compaction still fails, the app should offer a recovery action such as dropping old attachment payloads while preserving textual history, plans, worktrees, and parent/child session relationships.

### Additional context

Diagnostics from one occurrence:

- Automatic compaction started with `conversationTokens=238388`, `systemTokens=11778`, and `toolDefinitionsTokens=26868`.
- `BasicTruncator` reduced messages from 364 to 289 and tokens from 277034 to 258368, but the serialized request was still 5.5 MB.
- The event log contained many `session.binary_asset` records with inline base64 PNG data. One retained PNG was 855,114 bytes and its base64 field was 1,140,152 characters.
- There were ten consecutive `session.compaction_complete` events with `success=false` and the same 5.5 MB / 5.0 MB error.
- Recovery was possible only by stopping the session process, backing up the state, replacing that single old inline image payload with a tiny valid placeholder while leaving its metadata and original image file intact, removing the stale lock, and reopening the same session. The next tiny prompt succeeded immediately. This reduced the serialized history by about 1.14 MB, strongly indicating that retained inline binary data is included in the compaction request.
- The textual conversation, checkpoint summaries, plan, repository worktree, and all five related child sessions were preserved.
- Related reports: #2181, #788, #756, and #2265. Those describe the symptom; this report adds a reproducible document/image trigger, event-level diagnostics, and a verified recovery that isolates inline binary assets as the size source.

Start by tracing automatic compaction, BasicTruncator, session.binary_asset records, and the CAPI request serialization described in the diagnostics. Done means oversized compaction requests no longer permanently brick sessions, while textual history, plans, worktrees, and parent/child relationships remain recoverable.

索引モデルが issue の本文から書いたものです。