[Task]: wingetbot worker — Hash-mismatch class learnings

### Description Per-class learning tracker for the **wingetbot auto-update PR triage worker** (#411124). Use this issue to capture evidence, edge cases, and diagnosis heuristics for the **Hash-mismatch** class before/while building the worker. **Labels:** `Error-Hash-Mismatch`, `Validation-Hash-Verification-Failed` ### Current disposition (from the 2026-08-01 pilot) **Diagnose + route — never auto-fix.** The SHA256 in the manifest ≠ the file when the pipeline downloaded it. **Hard guardrail: never download the installer to re-hash** (integrity/security). ### Learnings so far - Example #410669 (codexu.NoteGen 0.30.0): InstallerUrl is a **version-pinned** GitHub release tag, yet the setup.exe hash changed *again* after wingetbot's own bump → the publisher **re-published** the release asset (a moving target even at a pinned URL). - No error-detail PR comment exists for this label (label-only); the evidence is the InstallerUrl + the manifest SHA256, not a log line. - Useful signal: is the InstallerUrl **version-specific** or a moving `latest`-style target? That distinction drives the diagnosis. ### Open questions / learnings to capture - [ ] How often is it a genuine re-publish (trust the new hash after human review) vs. a `latest`-URL package that should be pinned? - [ ] Can we detect re-publish vs. CDN flap without downloading (e.g. `Last-Modified` / `ETag` via HEAD)? - [ ] What is the safe recommend-only message for a moderator (verify current file, then `@wingetbot run`)? Parent: #411124 _Created with GitHub Copilot assistance._