Tell someone when the engine breaks

Everything that goes wrong already travelled the event bus, but the only
subscriber was the editor's websocket — so a flow quarantined at three in
the morning was invisible until someone opened the browser.

An alert manager now watches the same bus and forwards failures to ntfy,
email or a webhook. Most of what it does is decline to send: the same
node failing every second is one alert with a count of what followed, a
connection flapping up and down is muted until it settles, and nothing
gets past ten notifications an hour. Verified against a live instance —
six identical failures produced one alert carrying the real traceback
message.

Channels and rules are configured through the API, with a test send so a
channel can be proven before anything depends on it.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011LF61rxW1FG5YCD2J9YqjY

NOTEPAD.md

@@ -32,6 +32,8 @@ Deferring because out of scope is fine, but don't mention deferring than.
 - CHORE/INFRA: `requires-python` is capped below 3.14 because the MCP SDK wants a newer
   starlette there than the pinned `sentry-sdk<2` allows. Lift the cap when sentry-sdk moves
   to 2.x.
+- FEAT/UI: no screen for alerting. Channels and rules are API-only (`/alerts/config`),
+  so setting up a phone notification means calling the endpoint by hand.
 - FEAT/UI: there is no screen for managing the secrets store itself. A node parameter marked
   `x-secret` offers the stored secrets, but they can only be created through the API.
 - FEAT/FLOW: input discretization drops the trailing edge — if a producer goes quiet inside