fix: read push survives a locked Mac, and imsg-read says the screen is locked

[ianswope]

What

Three changes, one cause.

1. A per-chat read intent is never dropped. collect() used to delete pendingReads[chat] after five failed attempts. Now only --all is dropped on failure (it cannot be bounded); a per-chat intent keeps retrying at the existing backoff ceiling (once a minute) until the Mac confirms it or a newer inbound cancels it. Two new tests: a prolonged failure keeps the dot suppressed through seven attempts and recovery clears the queue with one more push; a newer inbound mid-retry cancels the intent, leaves the chat unread and sends nothing. The read-sync fixture also sets XDG_RUNTIME_DIR into its home: without that, a running blip-bridged answers underneath the tests on any machine that runs Blip, and the convergence test fails on clean main there. That test's budget goes from 20 s to 60 s; it spawns 96 collector processes and takes 10–16 s on an idle 16-core box.

2. imsg-read names the lock screen. When System Events fails or finds no Messages window, it now reads IOConsoleUsers[].CGSSessionScreenIsLocked from ioreg -n Root -d1 -a (no TCC grant involved; the key exists only while locked) and reports "the Mac's screen is locked …" with the cure, instead of "log in and open Messages on the Mac". The Accessibility-not-granted message keeps precedence.

3. Docs. README "Keeping the Mac awake" gets the lock screen as the third way a gateway goes dark, with the one-line fix, its trade-off and undo, and a Linux-side check. CLAUDE.md records the durable per-chat queue and the lock-screen finding.

Why

My gateway Mac mini never sleeps (sleep 0, displaysleep 0), never logs out, and Messages is always open. Under push_read=thread, every --chat push still failed with exit 64 "Messages has no accessible window" from about 25 minutes after I last touched it until I unlocked it again, and I had been "logging in" several times a day without understanding why. The mini's loginwindow log has the answer: screen saver at 20 idle minutes (targetUserIdle = 1200, the default), lock 5 minutes later (sysadminctl -screenLock status), and behind the lock screen count windows of process "Messages" is 0. The last failed push was at 10:26:05 today; LWScreenLock handleUnlockResult logged the unlock at 10:26:07; Blip was healthy two minutes later.

Two things made it worse than it had to be. The error text sent me to a Messages that was open and fine. And the collector dropped each per-chat intent after five attempts, so a conversation I had read in Blip came back as unread after the night. The intent was right; the Mac was just unreachable for it. Keeping the intent is safe because the read-state snapshot compare and --through already refuse to consume a newer inbound, and the second new test pins that.

The fix for the lock itself is on the Mac, not in Blip: defaults -currentHost write com.apple.screensaver idleTime -int 0. I applied it today and confirmed from the loginwindow log that when the armed timer fired at 10:46:07 it re-read idleTime: 0 and stood down. Nothing here touches #125's items (the per-poll snapshot, the blocking read action).

How it was verified

• bun test is green locally (748 pass, 0 fail). python3 bridge/mac/test_read.py 35 OK (three new), test_read_verification.py and test_read_sync.py OK, the CI py_compile line passes.
• screen_locked() run verbatim on the gateway (macOS 27.0.1, Python 3.9.6) against the live, unlocked session returns False. The locked branch is covered by the synthetic-plist test; I have not locked the mini on purpose to see it live.
• The collector change has run on my machine since yesterday: through last night's lock it kept two per-chat intents (441 and 409 attempts) and both pushed and cleared within minutes of the unlock, with no dot resurrected.
• Any send/receive behavior was exercised against my own number only: no send/receive behavior touched.
• UI change → screenshot attached: no visual change.
• Touches an invariant in CLAUDE.md → "Read sync is an acknowledged, durable action queue" (per-chat intents are never dropped) and the "Marking read ON THE MAC" notes (the lock screen); both updated.

[nixfred]

Merged, thank you Ian. A night of 441 failed attempts against a locked Mac, then a dot coming back for a conversation already read, is a great find, and "the Mac's screen is locked" is a far better message than sending someone to a Messages that is open and fine. Your fixture change also turned out to matter here more than you knew: with the persistent channel from #83 running on my machine, 15 read-sync tests on main were failing because the live socket answered underneath them; with your XDG_RUNTIME_DIR isolation all 750 pass. The new bridge is on my Mac and both Linux machines. One note for the record, not a change request: per-chat retries are now unbounded, so a permanent non-lock failure on an unlocked Mac would reopen the conversation once a minute; in practice opening it reads it and the snapshot retires the intent, and only push_read=thread or menu reads queue per-chat intents.