Epic 10: Observability and operational tooling

[mdproctor]

Build the operational surface devtown needs to run at scale — the equivalent of Gastown's `gt feed`, `gt problems`, `gt doctor`, `gt seance`.

Scope

• MCP tool: `get_devtown_queue_status` — current batch state, PRs queued, PRs in review, PRs blocked; callable by claudony's MCP endpoint
• MCP tool: `get_reviewer_health` — for each active reviewer: current obligation state, trust score by capability, last 5 outcomes
• MCP tool: `get_merge_audit` — causal chain for a specific merge batch: why bisected, which PR failed, who approved
• MCP tool: `list_devtown_stalled` — reviewers with OPEN commitments > threshold with no activity
• Claudony dashboard extension: devtown panel — review queue depth, batch status, trust score distribution by capability
• W3C PROV-DM export: LedgerProvExportService for merge decisions (foundation already provides primitives)
• OTel spans: case creation → binding fire → worker dispatch → commitment lifecycle — all correlated via `LedgerTraceIdProvider`

Reference: docs/gastown-casehub-analysis-v2.md §4.7 (observability comparison), §7 (Gastown operational tooling advantages)

Foundation gate: MCP tools can be added now. Dashboard extension needs claudony session. PROV-DM needs P2.3 (cross-repo causal chain).

Done when: An operator can see the full review queue state, identify stalled reviewers, and trace any merge decision back to its causal chain — from a single MCP tool call or claudony dashboard panel.