ryu-notify 0.1.8

Shared notification-delivery wire types + send primitives for Ryu: the swappable channel targets (webhook / Telegram / Expo push / BYO SMTP email recipient) and the dep-light HTTP send functions behind monitor alerts, policy alerts, workflow channel-send, and user-scoped notifications. The kernel notification STORE + fan-out orchestration stay Core-side (`apps/core/src/notify`); this crate holds only what Core and the out-of-process monitors engine BOTH need, so it has ZERO dependency on apps/core.
Documentation

Shared notification-delivery wire types + send primitives.

This crate is the narrow surface that both Core (the kernel notification store + fan-out orchestration in apps/core/src/notify) and the out-of-process monitors engine (apps-store/monitors/backend) need in common: the channel-target enum and the dep-light HTTP send functions. It has ZERO dependency on apps/core.

Placement (Core vs Gateway): a notification decides what runs (open a delivery socket) → Core-side. Nothing here is policy. The store, deliver_user_notification, dedupe, and the tiered notify_all fan-out that wires in the desktop event bus / plugin hooks / BYO SMTP live in Core; only the shared types + primitives live here.

The set of targets is an extensible enum — the "nothing hardcoded, everything swappable" rule applied to channels: a webhook covers Slack/Discord/any HTTP endpoint, Telegram is a direct Bot-API send, Expo handles mobile, and Email carries only the recipient (the SMTP transport is a shared node resource resolved once at the Core call site, never stored per-target).

Every send is best-effort unless its name ends in _text: those return Ok(()) only on a 2xx so a workflow node can surface a failed delivery.