backlog(#340): the armed-auto-merge signal is unfalsifiable from outside

docs/BACKLOG.md

@@ -8301,6 +8301,8 @@ Two worked instances the same day. **#74** went green on 2026-07-30 and sat unme
 
 *It is also a measurement cost, which is how this joins #344.* Supersession-and-re-run turns this population into one that **two different filters prune in two different ways**, and a margin read off either without naming it is not a margin. Filtering by **job** conclusion deletes rows where the job was cancelled but the *step* succeeded — the tightest rows, by construction, because a step near the cap is exactly what pushes its job past the job cap. The default **latest-attempt** view (`actions/runs/{id}/jobs`, `gh run list`) instead hides *failed earlier* attempts; it does not move a step-success maximum, but it conceals that the sample is **right-censored** — the largest step observable is the largest that *fit* under the cap, never the largest the suite wanted. Read `?filter=all` to see the censoring, and key on the **step's** own conclusion, not the job's.
 
+*The readiness signal cannot be distinguished from its own absence.* Re-measured 2026-08-02T13:41Z: of 14 open PRs, **9 carried armed auto-merge and 6 of those were inert** — five `BEHIND`, plus #71 armed *and* `DIRTY`, which cannot land at all. **Zero armed PRs were `CLEAN`.** Every session here reads `autoMergeRequest != null` as *"this will land"* — the author of this paragraph did exactly that about their own PR an hour earlier — when for two-thirds of them it means *"this waits until a human runs `gh pr update-branch`"*, with nothing reporting the difference. That is what lifts this item out of efficiency and into correctness: *"merges are slow"* has a **"then be patient"** answer; *"the merge-readiness signal is unfalsifiable from outside without a second query nobody runs"* does not. Same defect class as ADR 0158's — a green signal that means nothing — observed live rather than in retrospect.
+
 *The largest cost is protocol, not throughput.* With no queue, sessions invent an ordering ritual to compensate — and the ritual is less reliable than the mechanism it replaces. Self-reported instance from the same night: a session assured a peer it would not jump the queue **while its own PR had auto-merge armed** and would have landed with nobody deciding anything. [`WORKTREES.md`](WORKTREES.md) already names that failure — *"'Don't do X' is the wrong primitive when automation already has X armed"* — and that session had read the line, about this very freeze, hours earlier. Effort spent negotiating a merge order is effort a queue spends for free, and it is where the night's stale facts and unenforceable promises came from. Wall-clock a reader can dismiss as impatience; this is not that.
 
 **What a merge queue does not fix.** Stated level with the cost, because filing an overclaim inside the ticket about overclaiming would be its own instance: