U10 follow-up: verify cache invalidation covers auto-merged notes

[mattfogel]

Problem

prov notes-resolve calls invalidate_cache_per_sha(&git, resolved_shas) (notes_resolve.rs:86) with only the SHAs whose notes were conflict-resolved in the worktree. When git notes merge auto-merges some commits before parking conflicts in NOTES_MERGE_WORKTREE/, those auto-merged commits also have changed notes — but their SHAs aren't in the list passed to invalidation.

Why this might be a non-bug

invalidate_cache_per_sha (common.rs) also re-stamps recorded_notes_ref_sha at the end. If Cache triggers a cold reindex when recorded_notes_ref_sha != current_ref_sha, the re-stamp implicitly invalidates everything regardless of which individual SHAs were dropped — making the auto-merged set a non-issue.

Investigation needed

1. Read prov_core::storage::sqlite::Cache to see whether set_recorded_notes_ref_sha mismatch forces a cold reindex on next read.
2. If yes: close this issue as a non-bug, leave a comment in notes_resolve.rs:86 explaining the contract.
3. If no: collect all SHAs the merge touched and pass them to invalidation. Options:
   • Snapshot pre-merge git notes list --ref=prompts SHAs, post-merge re-list, diff the sets
   • Parse output of git notes merge --commit if it logs touched SHAs
   • Walk NOTES_MERGE_PARTIAL against the pre-merge ref to enumerate touched commits

Severity / Confidence

• Severity: P2
• Reviewer: reliability
• Confidence: 75
• Finding ID: notes_resolve.rs:86 — cache-invalidation-conflict-only
• Review run: `/tmp/compound-engineering/ce-code-review/20260503-110435-c2868c0f/`