watch: per-file acceptance granularity for high-churn vendor skills

[askalf]

Problem

watch-accepted.json entries accept a reviewed-benign skill for exactly these bytes (whole-skill hash). That is the right default — drift means re-review. But agentforce-adlc shipped twice on 2026-07-16/17 (v0.8→v0.9 within ~2h), and each release lapsed the acceptance and turned the public badge red until a human re-read the delta and shipped a re-accept PR (#65, #67). For actively-developed vendor skills this makes the badge flap red on every upstream docs release, even when the reviewed finding content is untouched.

Proposal — per-file acceptance granularity

Key the acceptance to the files that carry the reviewed findings (per-file hashes for the finding-bearing files) instead of the whole-skill hash:

• The reviewed fixture file(s) changing → acceptance lapses, re-flag (guarantee preserved where it matters).
• Unrelated files added/changed (new reference docs, version bumps) → acceptance holds; the scanner still runs on the full skill, so NEW findings in NEW files still flag on their own.

Notes

• The scan itself already re-runs on every sweep, so a malicious addition in a new file is caught by detection regardless of acceptance state — the acceptance only silences the known reviewed findings.
• Fallback thought: keep whole-skill hash as default, allow an explicit "granularity": "finding-files" opt-in per entry for high-churn vendors.
• Receipts for the churn: fix(watch): re-accept agentforce-generate after upstream docs-only drift #65 (docs-only permset verification), fix(watch): re-accept agentforce-generate after v0.9 upstream release #67 (v0.9 optimization workflow), both hand-reviewed benign; badge went red twice in one day between reviews.