feat(windows): add one tray and wait for Automation on send

[daveyb]

Why

Blip on Windows had no pull request yet. The tray in this branch is that client. Two problems showed up once it was running.

A second Start-menu launch opened a second Blip. The tray now takes the mutex Local\Nixfred.Blip. The second process sets Local\Nixfred.Blip.Show, the first process opens its window, and the second process exits.

A direct-message send died at 15 seconds in list_services. That call asks Messages for its services before --yes is checked, and 15 seconds is shorter than the Automation prompt. macOS records an unanswered prompt as a denial after about two minutes. run_osascript waits 150 seconds. On timeout it exits with one sentence, and the Windows bubble already displays that sentence.

Scope

• windows/BlipTray, windows/BlipShim, windows/text-send.ts, and scripts/win/install.ps1 are the tray, the shim, and the installer.
• Program.Instance owns the mutex and the show event.
• planTextSend chooses --to or --chat-id. The body stays on stdin.
• bridge/mac/imsg-send adds run_osascript and OSASCRIPT_TIMEOUT.
• bridge/mac/test_imsg_send_wait.py is the CI check for that wait.

Tradeoffs

Waiting 150 seconds does not grant Automation. If the Mac shows no prompt, the send still fails, and it fails later. No real iMessage was sent. The only acceptable target is the sender's own number, and this change does not know that number.

Finding the running window by its title was the other option. A proof window can use the same title, so the mutex is the key.

Blast radius

imsg-send is the Mac tool the Linux client already calls. A send that used to stop at 15 seconds now waits up to 150. Text sends and file sends share that wait. The Windows tray is new and installs for the current user. When the installer creates a config, push_read stays off. An existing host= is left alone.

Verification

py bridge/mac/test_imsg_send_wait.py failed while list_services waited 15 seconds and run_applescript waited 30. It passed after run_osascript.

The installed Mac tool, with a fake osascript that sleeps 20 seconds and prints one service line, printed RESULT timeout elapsed=15.03 on the old script and RESULT ok elapsed=20.17 on the new one. The installed file reports OSASCRIPT_TIMEOUT 150.

Two launches of the installed Blip.exe left one process. The startup log added up, then show, then shown.

No message was sent, no thread was marked read, and no conversation was opened.

[nixfred]

Thank you, David, and welcome. A Windows client for Blip is a real piece of work, and the single-instance mutex and the honest tradeoff notes show care.

I took the Mac-side fix: your two commits (imsg-send waits 150 s for the Automation prompt, and test_imsg_send_wait.py in CI) are on main with your authorship, b440a49 and 1b55b40. That helps every Blip user: a first send no longer dies before anyone can click Allow, and it matches Blip's own rule about never cutting a consent prompt short. It is live on my Mac.

The Windows tray I would rather not carry in this repo. Blip is built and tested as an Omarchy plugin, I can't build or test C# here, and every Windows bug would land on a reviewer who can't reproduce it. It deserves an owner who runs Windows. If you publish it as its own repo (blip-windows, say) using this repo's bridge as the Mac side, I will link it from the README, and bridge changes you need are welcome here as PRs like this one. I'm closing this PR on that basis; please don't read it as a no to the work.

One small ask: I thank contributors by name in a weekly post on X. Is there an account you'd like tagged? "Rather not be tagged" is an equally good answer.