fix(toasts): clicking a message notification opens its conversation

[ianswope]

Problem

Clicking a Blip message notification only dismissed it. The toast's omarchy-exec-argv hint runs qs ipc call nixfred.blip goto <chat>, and goto is refused unless automation=on in bridge.conf. Omarchy's daemon runs the hint in preference to the live default action (Service.qml invokePopupDefault), so with the default automation=off nothing happened.

Fix

• New ungated IPC notified <chat>, used by the toast hint.
• It opens the conversation only when Blip toasted that chat this session (in-memory, newest 64) or the chat is still unread; otherwise it opens the list. A local process cannot use it to open (and so mark read) an arbitrary conversation, which is what the automation gate protects.
• goto and the rest of the automation-gated IPC are unchanged. Code toasts are unchanged (transient, no hint, click copies).

Verified

• bun test: 750 pass.
• Deployed, shell restarted, no plugin errors in the qs log.
• Posted a toast carrying the same hint and fired the daemon's click (notifications invokeLast): Blip opened (list, since that chat had not been toasted).

[nixfred]

Merged, thank you Ian. Every message toast was a dead click for anyone on the default automation=off, because the daemon prefers the hint over the live action and goto refused it. Scoping the new ungated door to chats Blip toasted or that are still unread is the right line, and it returns only "shown"/"opened", never content. Live on both my machines; a click on an unknown id opens the list as designed.

One small note for the record, not a change request: because the two answers differ, a same-user process can learn whether a chat id is unread or was just toasted by calling notified and reading the reply. Each probe visibly pops the panel open, so it is noisy and low risk. If you ever touch this again, returning one fixed string would close it.