Owner notices: the stall, one webhook path from env to Discord (#171)

Rollout note: the owner_notices table starts empty, so the first pass after deploy sends for conditions already true — correct per one-row-per-episode; say so rather than have it reported as a bug. Prod step: create the webhook, set DISCORD_WEBHOOK_URL on the deployment, redeploy — unset is silent by design, and without that step the feature ships dark. Security invariants preserved: the webhook address is a secret in the class of TOKEN_KEY (never logged, never on a config-printing line), and the owner gate is unchanged.

.env.example

@@ -99,7 +99,13 @@ DISCORD_REDIRECT_URI=
 # request whose Host header isn't an IP or "localhost", which silently breaks
 # every kagane poll. Left unset here on purpose — a wrong default would poll a
 # stranger's address, and "no browser" is a safe, self-announcing state.
-# BROWSER_WS_URL=ws://100.x.y.z:9222
+# Discord webhook for owner notices (outbound alerting when a poll Lane
+# stalls). Unset means the whole path is off — a local stack needs no webhook,
+# exactly as the browser URL behaves. The address is a secret in the class of
+# TOKEN_KEY: never commit it, never paste it anywhere public.
+# DISCORD_WEBHOOK_URL=https://discord.com/api/webhooks/...
+
+# Zone the backend stamps its log lines in. Cosmetic only. Nothing else in
 
 # Zone the backend stamps its log lines in. Cosmetic only. Nothing else in
 # the service has a zone: bookmark timestamps are unix ms, and the two real