(orchestration): Context quality metrics on task completion

## Component

API or orchestration

## Describe the feature

Emit and persist **context-quality signals** per task at completion: tool-call count, unique files touched, hydration token usage, retry/verify loops, turns consumed vs. budget, and optional “scope expansion” flag. Expose in API, CloudWatch metrics, and `bgagent stats`.

## Use case

High tool-call counts and repeated verify failures often indicate **missing harness context** rather than model weakness. Production teams use **tool calls per session** as a proxy: more curated skills/rules → fewer exploratory tool calls → faster task completion. Platform teams need this metric to prioritize repo onboarding and detect context drift after refactors.

## Proposed solution

1. Agent `progress_writer` / runner aggregates counters during execution.
2. Orchestrator writes `context_quality` object on task record and terminal `TaskEvent`.
3. CloudWatch embedded metric format for `ToolCallsPerTask`, `VerifyRetriesPerTask`.
4. Dashboard widget in operator dashboard; optional alarm on p95 tool calls per repo.

## Other information

- Complements roadmap **LLM-assisted trace analysis** (post-mortem) with cheap always-on counters.
- Pairs with **feature-service-catalog-context-hydration** and **Dynamic onboarding artifacts**.

## Acknowledgements

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

## Acceptance criteria

- [ ] Terminal tasks include `context_quality` in API responses when execution reached RUNNING.
- [ ] Metrics visible in CloudWatch with `repo` and `workflow_ref` dimensions.
- [ ] Documented interpretation guide in `EVALUATION.md`.
- [ ] Unit tests for aggregation logic in agent and handler layers.

Inizia individuando l’agente progress_writer o runner, il record dell’attività dell’orchestrator e la gestione dei TaskEvent terminali, nonché i punti di ingresso della dashboard dell’operatore e delle metriche CloudWatch. Traccia il percorso dei dati di completamento fino alle risposte dell’API, quindi esamina EVALUATION.md e i test esistenti di handler e agenti. Il lavoro è completato quando i criteri di accettazione elencati sono coperti nell’aggregazione, nella persistenza, nelle metriche, nella visibilità della dashboard, nella documentazione e nei test.

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