docs(worktrees): the freeze bullet had the right lesson and the wrong reason

Routed here by the ADR 0154 session because I was the one live in this
file. I had already corrected the false half -- "#119 never merged" -- but
only to "it merged the following day", and their framing is better, so this
takes theirs.

The failure was never that the condition could not arrive. #119 merged
(2026-08-02 01:45:00Z, 002be18). It is that THE WORLD MOVED WHILE EVERYONE
WAITED: main advanced four times first -- #74 20:27:03Z, #120 23:59:43Z,
#131 00:35:29Z, #130 01:01:35Z. So the freeze did not hold main still even
while nominally in force. It held only the sessions honouring it, which is
the worst of both, and it is a sharper argument for the same bullet without
resting on a false fact.

Every timestamp re-verified against the API here rather than restated; the
measurements are theirs. The same framing was independently corrected in
ci.yml (07b6e55) and in BACKLOG #340, making this the third document to
carry it and the last one live.

Also names what the bullet had become: a compensating control resting on a
false premise, which is the failure CLAUDE.md §11 lists -- occurring inside
the document that argues for the rule. That is worth one sentence, because
the next stale premise will look just as settled as this one did.

Author: wshallwshall

docs/WORKTREES.md

@@ -428,12 +428,28 @@ it by hand. Three constraints came out of that, recorded here so the next attemp
 them:
 
 - **A broadcast needs an expiry or a predicate the *recipient* can evaluate — never a promise from the
-  sender.** A merge freeze went out with "lift when #119 merges". #119 did not merge that day (an
-  unrelated CI timeout), so five sessions held on a condition that had not arrived and it took a second
-  round to retract. It merged the *following* day, 2026-08-02 01:45Z — which sharpens the point rather
-  than softening it: the recipients had no way to evaluate the predicate, so the freeze outlived its
-  own condition in both directions. As of 2026-08-02 a claim note still announcing that freeze was
-  being read by every joining session hours after both it and #133 had merged.
+  sender.** A merge freeze went out with "lift when #119 merges", and five sessions held. **#119
+  merged** — 2026-08-02 01:45:00Z, merge commit `002be182`. The failure was never that the condition
+  could not arrive; it was that **the world moved while everyone waited**. `main` advanced four times
+  before it did:
+
+  | | |
+  |---|---|
+  | #74 | 2026-08-01 20:27:03Z |
+  | #120 | 2026-08-01 23:59:43Z |
+  | #131 | 2026-08-02 00:35:29Z |
+  | #130 | 2026-08-02 01:01:35Z |
+
+  So the freeze did not hold `main` still even while it was nominally in force — it held only the
+  sessions honouring it, which is the worst of both. And it outlived its own condition in the other
+  direction too: on 2026-08-02 a claim note still announcing the freeze was read by every joining
+  session hours after #119 had merged. A predicate the recipient cannot evaluate does not expire.
+
+  This bullet said "#119 never merged" for a day, which made it a compensating control resting on a
+  false premise — the failure [`CLAUDE.md`](../CLAUDE.md) §11 names, inside the document arguing for
+  it. Corrected against the API, and the same framing was independently corrected in `ci.yml`
+  (`07b6e55a`) and in BACKLOG #340 by two other sessions; timestamps above are theirs, re-verified
+  here rather than restated.
 - **"Don't do X" is the wrong primitive when automation already has X armed.** The freeze asked
   sessions not to merge, while six PRs had auto-merge *armed* and would have landed with nobody
   clicking anything. The correct ask was an action — "disarm auto-merge" — not restraint.