OIC event-driven staleness and targeted re-evaluation #237

Context

Staleness can't be just "older than N days". A deploy instruction goes stale after a config change, and a flaky-test observation applies to a specific commit and environment. Start after #235.

Behavior to implement

• When new evidence arrives (a commit touching a described config, a CI run contradicting a test claim, a new decision, a user report), find the claims it may affect and mark them stale, or queue a focused re-check investigation.
• Staleness rules per claim type, with an optional review_due_at. Time-based review is only a fallback.
• The reason a claim is stale is visible in the API and UI.

Acceptance criteria

• A commit changing a file referenced by an active claim's evidence marks that claim stale, with the commit as the reason.