chore(ledger): the LFS hook pollution recurred — hazard, not slip

Removed once this afternoon; back within two hours, triggered by an LFS filter
running during the git-vs-LFS storage measurement. git-lfs installs its hooks
into whatever core.hooksPath names, which here is the global hook directory.
Any LFS operation in any repo on this machine writes four shims there.

Deliberately not gitignored: they show as untracked files in dotfiles status,
and ignoring them would hide the pollution rather than surface it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NvZAKSf9aqratbqHbU9LK5

claude/memory/session-ledger-2026-08-26.md

@@ -31,6 +31,15 @@ type: feedback
   ⚠ **Another PENDING-160 instance, made by the party that spent the morning writing it up:** a
   flag named `--local` meant something else because of a setting one layer out.
 
+- 2026-08-26T~evening — ⚠ **The LFS hook pollution RECURRED, and that makes it a hazard
+  rather than a slip.** Removed once; it came back the moment an LFS *filter* ran during the
+  git-vs-LFS storage measurement — git-lfs re-installs its hooks into whatever `core.hooksPath`
+  names, and here that is the steward's **global** hook directory. **Any LFS operation in any
+  repo on this machine writes four shims into `~/dotfiles/git/hooks/`.** Detectable — they show
+  as untracked files in `git status` on dotfiles — and deliberately NOT gitignored, because
+  ignoring them would hide the pollution instead of surfacing it. ⚠ Care did not prevent the
+  second occurrence; I had cleaned the first one two hours earlier.
+
 ## What held
 
 - Ran `thread-query.py` on the actual thread and reported the **null honestly** (689 candidates,