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

Inizia nella directory agent/ e segui come vengono gestiti gli errori dei post-hook, i TaskEvents, la configurazione del blueprint e gli artefatti di sessione. Definisci prima il comportamento del percorso di retry autonomo e il confine di archiviazione, quindi usa log di fixture di diversi KB per verificare che i riepiloghi conservino i nomi dei test falliti e i percorsi dei file, che i log completi abbiano URI recuperabili e che la documentazione venga aggiornata in COMPUTE.md o nel README di agent.

Scritto dal modello di indicizzazione a partire dal testo della issue.