Agent: Context compaction policy for tool and verification outputs

> **Roadmap:** In-pipeline build/lint fix-up loop; Memory token budget (shipped)
> **Priority:** P2

## Component

Agent (Python runtime)

## Describe the feature

Implement **context compaction** for large tool and verification outputs (build logs, test failures, linter diagnostics) before re-injection into the agent context. Full-fidelity artifacts are offloaded to durable storage with retrievable handles; the active prompt receives structured summaries only.

Addresses arXiv:2605.18747 §3.2.6 (context compaction and state offloading): long-horizon tasks overload context with noise and obscure decision-relevant evidence.

## Use case

- **In-pipeline fix-up loop** (roadmap) needs failure summaries, not 50 KB of raw Maven output, on retry turns.
- **Nudge and long tasks** avoid context explosion from accumulated tool output.
- **Token budget** is spent on actionable signals, not log spam.

## Proposed solution

1. Compaction function in `agent/` (e.g. `context_compaction.py`):
- Input: raw command output + sensor type (`verify_build`, `verify_lint`, shell)
- Output: `{ summary, structured_fields, full_artifact_uri }`
- Structured fields example for test failure: failing test name, key stack frames, suspected files

2. Store full output to session workspace or S3 prefix; emit `TaskEvent` with URI.

3. Blueprint-configurable policy: `compaction: default | aggressive | off` (default: compact on retry paths).

4. Emit OTEL metric: tokens before/after compaction.

### Acceptance criteria

- [ ] Compaction applied when post-hook failures are fed back to agent (when fix-up loop ships) OR on a standalone retry path behind flag for initial delivery
- [ ] Full log preserved at retrievable URI referenced in TaskEvents
- [ ] Unit tests with multi-KB fixture logs; summary preserves failing test name and file paths
- [ ] Documented in `COMPUTE.md` or agent README; token impact noted in `COST_MODEL.md` if measurable

## Other information

- **Complements:** In-pipeline build/lint fix-up loop (roadmap)
- **Paper:** arXiv:2605.18747 §3.2.6
- **Existing:** ~100K hydration budget, 2K memory budget (orchestrator-side)

## Acknowledgements

- [ ] I may be able to implement this feature
- [ ] This might be a breaking change

Beginne im agent/-Verzeichnis und verfolge, wie Fehler in post-hooks, TaskEvents, die Blueprint-Konfiguration und Sitzungsartefakte behandelt werden. Definiere zuerst das Verhalten des eigenständigen Retry-Pfads und die Speichergrenze und verwende dann mehrere KB große Fixture-Logs, um zu überprüfen, dass Zusammenfassungen die Namen fehlgeschlagener Tests und Dateipfade beibehalten, vollständige Logs abrufbare URIs haben und die Dokumentation in COMPUTE.md oder der agent README aktualisiert wird.

Vom Indexierungsmodell aus dem Issue-Text verfasst.