Introduces AlertV2Definition - a new model that lets users define TSQL
queries and threshold conditions that trigger alerts on a configurable
evaluation interval. Results are recorded in ClickHouse for history and
auditing.

Key components:
- AlertV2Definition Postgres model: query string, conditions JSON,
  evaluationIntervalSeconds, alertChannelIds, state (OK/FIRING)
- alert_evaluations_v1 ClickHouse table: every evaluation result with
  state, value, duration, and error (90-day TTL)
- scheduleAlertEvaluations cron job (every minute): finds definitions
  due for evaluation and enqueues individual jobs
- evaluateAlertDefinition worker job: runs TSQL query with full tenant
  isolation, evaluates all conditions, writes to ClickHouse, fires
  ALERT_V2_FIRING / ALERT_V2_RESOLVED notifications on state change
- Delivery via existing Slack, Email, and Webhook channels; new alert
  types handled in deliverAlert.server.ts without breaking v1 behaviour
- Global concurrency limit enforced by the alerts Redis-worker pool

https://claude.ai/code/session_01XAz7T33otDLy9G8wz1cS6c

…ClickHouse writes

Replace the cron-based scheduler (one job scanning all alerts) with a
per-alert self-scheduling pattern: each alert definition is an independent
job in Redis-worker that re-enqueues itself for the next interval after
each run. This is more scalable — no global scan, and alert chains run
fully independently.

Changes:
- Remove v3.scheduleAlertEvaluations cron job and scheduleAlertEvaluations.server.ts
- evaluateAlertDefinition: after a successful evaluation, enqueue the next
  run at now + evaluationIntervalSeconds if the definition is still enabled;
  if deleted or disabled, the chain terminates naturally
- ClickHouse inserts are now fire-and-forget (no await, errors are logged)
- Add createAlertV2Definition.server.ts: creates the definition and
  enqueues the first evaluation job; also exposes static enable/disable
  helpers that restart or terminate the job chain

https://claude.ai/code/session_01XAz7T33otDLy9G8wz1cS6c