github-fetch-bumplisted

# Bump fetchFromGitHub pins Run from the worktree root. Scope: `fetchFromGitHub` only (not flake `github:` inputs, not other fetchers). Audit every pin, show a table, then after confirmation update the chosen ones end-to-end. ## Audit 1. Find every `fetchFromGitHub` pin in the nix setup (`overlays/`, `home-manager/`), excluding build artifacts (`result/`, `.direnv/`). Note each pin's `owner`, `repo`, `rev`, and surrounding `version`. 2. Classify each pin: - `tag` — `rev` is a tag string (e.g. `v1.2.3`, or `"v${version}"`). - `rev` — `rev` is a raw 40-hex commit SHA. - `needs-review` — `rev` is a PR-head / non-ancestor SHA (a comment or CHANGELOG hints it), e.g. jj built from an unmerged PR. 3. Per fetch, look up on GitHub (`gh` is authenticated): the default-branch head (sha + committer date), the latest release (tag + date; may not exist), and the commit delta from the pinned rev to the proposed target (ahead-by count + ahead/behind/diverged). 4. Proposed new pin — match the current pin type: `tag` → latest release tag; `rev` → latest branch-head SHA. Always show the latest-rev committer date (even for a tag) so AP can override. 5. Change summary: the ahead-by commit count + a 1-2 line headline from the commit range / release notes. Deep-dive (read CHANGELOG / PR / release notes, or spawn a sub-agent) only when the pin is non-standard or the delta looks risky. 6. Present one table: `fetch (file) | current | proposed-new | latest-rev date | status