improvise-29w2: a CLOSED PR the loop waits on (MERGEABLE/BLOCKED) pins the state check at the loop top

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VdfEGXA7aJ6ftMsCc9PJze

context/code/tooling.md

@@ -286,8 +286,13 @@ The rule now:
   already merged, and can come mid-wait when someone merges it during the watch.
   A merged PR reports `UNKNOWN/UNKNOWN` permanently (#189, read live), so the
   UNKNOWN wait slept the whole timeout there and then blamed mergeability. A
-  closed one need not: #74 reads `CONFLICTING/DIRTY`, which already ended the
-  wait, but as a misleading exit 1. The script now fetches `state`. Exit 5 is
+  closed PR's mergeability is whatever it was when it closed, so it can land on
+  either side of the wait. #74 reads `CONFLICTING/DIRTY`, which ends the loop at
+  once, but as a misleading exit 1. #46 has green checks and reads
+  `MERGEABLE/BLOCKED`, which the loop waits on, so it slept the full timeout
+  too (improvise-29w2). The suite carries all three shapes, and only the
+  waited-on ones can tell whether the state is checked at the top of the loop.
+  The script now fetches `state`. Exit 5 is
   its own code, not 1 or 0, because under merge-as-soon-as-green "someone else
   already merged it" is a normal answer, and the caller should hear it as that.
 - **The head checks come first, and the ended check after them**