Model structured code-quality findings in diff review

[johannesjo]

Context

The diff viewer supports human review annotations and can send them back to the active agent. Automated findings should use the same review loop instead of introducing a separate results UI.

GitHub Code Quality exposes a useful finding shape—rule, severity, category, source location, explanation, and state:
https://docs.github.com/en/rest/code-quality/code-quality

Scope

• Define a provider-neutral QualityFinding contract with:
  • stable ID/fingerprint
  • source/provider and rule ID
  • reliability or maintainability category
  • error, warning, or note severity
  • file and line/column location
  • plain-text/Markdown explanation
  • open, dismissed, or resolved state
• Render findings inline in the existing diff review and in its sidebar.
• Visually distinguish automated findings from human comments.
• Allow one or multiple findings to be sent to the selected task agent as structured remediation feedback.
• Reconcile findings after the diff changes so stale locations are not silently presented as current.

Non-goals

• Building a scanner in this issue
• Automatically committing fixes
• Blocking merges
• GitHub-specific authentication or APIs

Acceptance criteria

• At least one fixture provider can supply findings to the diff viewer.
• Findings navigate to the correct file and line.
• Severity and category are conveyed with text as well as color.
• A user can dismiss a finding or send it to the active agent.
• Findings that no longer match the current diff are marked stale or removed deterministically.
• Contract and reconciliation behavior have focused tests.

[LarryHu0217]

I’m working on this as the provider-neutral foundation for #238: an injectable fixture provider, a tested finding/reconciliation contract, inline and sidebar presentation distinct from human comments, and single/multi-select send-to-agent actions. This will not add scanner or GitHub API behavior.