docs(release): add Evidence section to reaper squash-merge fragment

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Author: Instar Agent (echo)

upgrades/next/reaper-squash-merge-aware.md

@@ -23,6 +23,24 @@ deleted), and any `gh` failure fails safe to the legacy cherry-only behavior (KE
 Config: `monitoring.agentWorktreeReaper.githubMergeCheck` (default `true`; set `false` to
 disable the GitHub call). The reaper still ships OFF + dry-run by default.
 
+## Evidence
+
+**Reproduction / observed before:** On the affected machine, `git worktree list` showed
+~290 worktrees totalling ~118GB. The 28730 diagnostic session manually verified ~30 of
+the worktrees the reaper was KEEPING against GitHub and found their branches had MERGED
+PRs (e.g. #1041, #577, #1209) — i.e. the content was already in `main` — yet `git cherry`
+reported them unmerged (multi-commit branches squash-merged into one commit have
+different SHAs/patch-ids), so the reaper's verdict was `unmerged` → KEEP, forever. It
+manually reclaimed 27 of them (~5GB freed) only by checking GitHub by hand.
+
+**Observed after (this fix):** `isMerged` now returns `true` for exactly that case — a
+multi-commit squash-merged branch whose merged-PR head OID matches the worktree HEAD —
+so the reaper classifies them `reap-eligible` instead of keeping them. Unit tests pin
+both sides: the squash-merge-via-PR-map case returns merged; a branch advanced past its
+merge (OID mismatch) is still KEPT; gh-unavailable falls back to cherry-only (KEEP). The
+real-git end-to-end test ("reaps merged+clean, keeps dirty+unmerged") exercises the live
+deps and degrades safely when gh can't resolve the test repo.
+
 ## What to Tell Your User
 
 If a user asks "why is my disk full of merged worktrees that never get cleaned?" — the