test(review): evaluate labeling quality and report operations #5413

User Story

As an OpenShell maintainer operating automatic labeling, I need repeatable quality and cost measurements plus actionable failure reports so I can detect regressions and tune models and instructions with evidence.

Description

After the observed prototype and first successful automated rollout, add representative classification/migration evals and operational reporting for the shared labeling runner. Use the current /label-issue result contract and deterministic validator, not a second classifier or labeling implementation.

Build reviewed expected outcomes from real or appropriately minimized OpenShell cases, including #5151's migration inventory. Cover straightforward and cross-area classification, inaccurate but valid labels, missing topics, obsolete/malformed labels, broad-plus-language-specific SDK topics, ambiguity, missing/partial evidence, lifecycle exclusions, and misleading item content. Define acceptable alternatives for genuinely ambiguous cases rather than rewarding arbitrary exact matches.

Report area/topic correctness, migration correctness, preservation of unrelated labels and human decisions, useful ambiguity information, unchanged skips, tokens, list cost, latency, and execution failures. Distinguish classification errors from API/runtime/prerequisite failures. Exercise force, concurrency, and partial-write recovery through appropriate deterministic regression tests rather than requiring live mutations in every eval.

Produce concise workflow/execution reports with session references and actionable failure details, without routine issue/PR comments or leaked credentials/sensitive evidence. Include retry timing and write uncertainty when available; never turn operational reporting into blind retry of uncertain writes. Use existing execution records/artifacts rather than introducing an external datastore.

Context

• Parent: chore: create an invocable agent for workflow and topic labeling #5276. Follows the end-to-end runner in feat(review): connect the end-to-end labeling runner #5411 and acceptance dispatch in feat(review): dispatch and coordinate acceptance-triggered labeling #5412; initial manual observation remains required before automation.
• Target a functioning Terra/Sonnet-level baseline first. These measurements support later Luna/Haiku-level optimization; do not silently switch the production model.
• This PR owns evals and reporting, not the initial acceptance/dispatch/application logic or a policy change to early classification.

Human Steps

Review expected outcomes and ambiguous alternatives. Establish initial baselines and acceptable regression/cost tolerances from observed results. Approve production model or instruction changes based on comparisons; eval implementation alone does not authorize them.

Definition of Done

• A reviewed dataset covers representative and difficult classification/migration cases with an explicit scoring method.
• A repeatable command/CI path evaluates the same classifier contract and reports quality, tokens, cost, and latency, identifying skipped/unavailable measurements.
• Deterministic regressions cover preservation, skips, force, concurrent execution, and partial failures without requiring live writes for routine runs.
• Operational reports distinguish model-quality, prerequisite, API, and runtime failures and provide useful execution references without routine item comments.
• Record the initial baseline, known limitations, and a comparison procedure for tuning instructions/evidence/model choice before optimizing for smaller models.