(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.

Comienza localizando el agente progress_writer o runner, el registro de tarea del orquestador y el manejo de TaskEvent terminales, así como los puntos de entrada del panel del operador y de las métricas de CloudWatch. Traza cómo llegan los datos de finalización a las respuestas de la API y, después, revisa EVALUATION.md y las pruebas existentes de handlers y agentes. Se considera terminado cuando los criterios de aceptación enumerados están cubiertos en agregación, persistencia, métricas, visibilidad en el panel, documentación y pruebas.

Escrito por el modelo de indexación a partir del texto del issue.