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

Bắt đầu bằng cách xác định agent progress_writer hoặc runner, bản ghi task của orchestrator và phần xử lý TaskEvent ở trạng thái kết thúc, cùng với các entry point của dashboard dành cho operator và metric của CloudWatch. Theo dõi cách dữ liệu hoàn tất đến được các response của API, sau đó xem lại EVALUATION.md và các bài test hiện có cho handler và agent. Công việc được xem là hoàn tất khi các tiêu chí chấp nhận được liệt kê đã được bao phủ trong phần tổng hợp, lưu trữ bền vững, metric, khả năng hiển thị trên dashboard, tài liệu và test.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.