runner: operator alerts on job failure/recovery

[unforced]

Summary

Closes the R1 gap in the daemon's risk register: a scheduled #agent/job fire
failing wrote lastStatus: "error: ..." on the note and nothing else
happened. Every silent failure to date (e.g. a rate-limited 4am weave that
produced no report and went unnoticed for a day) was found by the operator
checking by hand, not surfaced by the system.

• src/runner.ts — the Runner now detects an ok↔error transition per
  job fire and calls an optional injected notify(event) hook: always on a
  fresh failure into error (including a job's very first fire failing),
  throttled to at most one alert per 24h on a job that's still failing
  (no spam on a stuck job), and always once on recovery (error → ok).
  Same "inject the side effect, keep the core pure/testable" shape as the
  existing loadJobs/fire/persistFire seams — no real clock/transport in
  the decision logic itself.

• src/daemon.ts — buildJobAlertNotify() wires that hook to the existing
  Telegram transport's reply() send path (no new transport, no new
  external API surface). Gated on two new env vars:

  • PARACHUTE_AGENT_ALERT_CHANNEL — name of an already-configured telegram
    channel (channels.json) whose bot sends the alert.
  • PARACHUTE_AGENT_ALERT_CHAT_ID — the chat id (DM or group) to send it to.

  Both unset → silent no-op (today's behavior, unchanged). Exactly one set →
  logs a loud warning once at boot. Both set but the named channel isn't a
  live telegram transport → logs + drops per-alert (checked at send time, not
  boot, so a channel added later is picked up without a restart). An
  alert-delivery failure is caught by the runner's notify guard and never
  breaks the tick — the circuit-breaker discipline in Runner.tick() is
  preserved.

• CLAUDE.md — documents the two new env vars in the existing table.

Test plan

• bun run typecheck — clean
• bun test ./src/ — 1490 pass, 0 fail (1476 baseline + 14 new)
• runner.test.ts: ok→error alerts once; a job's first-ever fire failing
  alerts too; ok→ok never alerts; error→ok fires exactly one recovery
  alert; a throwing notify is swallowed (tick still resolves, bookkeeping
  still persists); a still-failing job is throttled to ≤1 alert per window
• daemon-job-alerts.test.ts (new): env-var resolution (unset / partial /
  both set); unreachable/non-telegram alert channel drops without
  throwing; a live TelegramTransport sends via reply() with the
  configured chat_id and a message containing job id / agent channel /
  cron / error / note path; a recovery event's message has no error/note
  detail; a reply() failure propagates out of notify (so the runner's
  guard is what's responsible for swallowing it, not the notify builder)

Not deployed, not merged to main, running daemon untouched.