docs(cache): recommend delete-on-merge, and say what ancestry still covers

`daniel/zemyna` enabled `default_delete_branch_after_merge` after this
branch was written, so the deleted-branch signal will fire there on
future merges. That makes the setting worth recommending — it is the
cheapest case for this scheme, decidable from `ls-remote` with no
checkout, no objects and no walk — and it does not make the ancestry
signal redundant.

Three things it leaves behind, now enumerated in the README's eviction
section rather than implied: every branch merged before the setting was
turned on, of which zemyna carried 48 and which nothing retroactively
deletes; every merge whose deletion the forge declines or is never asked
to make, since it is best-effort and silent and an API merge without the
flag never asks; and every repo that has not enabled it, which is the
default.

Two present-tense claims about one repo's configuration are reworded
into the conditions they were standing in for, in prune-cache.sh's
header and beside is_merged_dead, plus the two in the selftest that
asserted the forge keeps branches rather than describing the fixture.
No behaviour change; the suite is green and unchanged at 61 assertions.

Refs #20.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JXMQCJ5Eg5f9G9cfYzyh4Z

README.md

@@ -278,15 +278,29 @@ the obvious order, because a snapshot is hardlinked to everything cloned from
 it, so removing one frees almost no real bytes while costing every future PR
 its warm start.
 
-**A branch is dead in two ways, and the second is the one that reclaims
-anything here.** Gitea keeps a PR's branch after the merge unless the repo
-opts into delete-on-merge, so `git ls-remote` reports merged branches forever
-and "gone from origin" fires for almost nothing. The second signal is
+**A branch is dead in two ways, and neither signal makes the other
+redundant.** The first is that the branch is gone from origin. The second is
 ancestry: a branch still on origin whose tip is an ancestor of a protected
 branch's tip holds no commit that branch does not, so its cache will never be
-read again and goes in the same pass. On zemyna's volume that is the
-difference between reclaiming nothing and reclaiming a 40 GB directory per
-merged PR (gitdan-actions#20).
+read again and goes in the same pass.
+
+**Turn delete-on-merge on** (`default_delete_branch_after_merge`, per repo) —
+it is the setting this scheme is cheapest under, because a deleted branch is
+decidable from `ls-remote` alone, with no checkout, no objects and no walk.
+The ancestry signal is what covers the rest, and the rest is not a corner:
+
+- **Every branch merged before the setting was turned on.** They stay on
+  origin forever; nothing retroactively deletes them. zemyna carried 48 of
+  them at the time the setting was enabled, and ancestry is the only thing
+  that reclaims a cache dir belonging to any of them.
+- **Every merge the deletion declines or fails.** Gitea's delete is
+  best-effort and silent: it declines for a protected branch and for one
+  another open PR still uses, and an API merge that omits the flag — which
+  `tea pulls merge` does — simply never asks.
+- **Repos that have not enabled it**, which is the default.
+
+That is the difference between reclaiming nothing and reclaiming a 40 GB
+directory per merged PR on a full volume (issue 20).
 
 Ancestry is answered from the commits in the job's own checkout, so it is only
 answered where they are there to answer it — and "cannot tell" is never folded