Auto-resolve findings when code changes (fingerprint + tree-sitter) #399

Problem

When code is fixed after a review, old findings linger as open forever. There is no mechanism to auto-resolve findings when the underlying code changes.

Solution

After each review/scan, auto-resolve previously open findings whose code no longer exists.

Algorithm

1. After saving new findings to DB:
2. Get all 'open' findings for this project
3. For each open finding:
   a. Compute fingerprint(file, line, title)
   b. Check if same fingerprint exists in current review's findings
   c. If NOT found → the issue may be resolved
   d. (Optional) Tree-sitter check: parse file, check if code node at line still exists
   e. If confirmed resolved → UPDATE status='solved', INSERT finding_event (auto_resolved)

Fingerprint Dedup

• Same code pattern = same finding across reviews
• Prevents duplicate noise when the same issue keeps appearing
• Uses hash(file:line:title_normalized) — already defined in Save review findings to cora.db (v5 tables) #397

Tree-sitter Enhanced Resolution (Phase 2)

When the tree-sitter feature is enabled:

• Parse the file at the finding's line
• Check if the AST node still exists at that range
• If the function/block was deleted or significantly changed → auto-resolve
• More accurate than line-only heuristic (handles code movement)

Dependencies

• Depends on: Migration v5: reviews, findings, finding_events tables #396 (v5 schema), Save review findings to cora.db (v5 tables) #397 (db_writer with fingerprint)

Acceptance Criteria

• Open findings automatically resolved when code changes
• Finding created with auto_resolved event in finding_events
• Fingerprint dedup prevents duplicate findings across reviews
• Tree-sitter check is gated behind feature flag
• Manual override: user can re-open auto-resolved findings
• Works for both review and scan findings