Phase 3: dashboards and alerting

Saved, shareable multi-panel dashboards (table/line/bar/single-stat
panels via gridstack + uPlot, global + per-panel time range, JSON
export/import) and threshold/absence alert rules with an
ok/pending/firing evaluator and webhook/Slack/PagerDuty delivery.

- New /metadata component: Postgres control-plane store for dashboards,
  panels, notification targets, alert rules/state, and delivery log --
  see docs/phase-3-dashboard-design.md for why ClickHouse's MergeTree
  family isn't a fit for this access pattern (needs real row-level
  locking and read-your-writes consistency).
- api/internal/dashboards: dashboard/panel CRUD, pure -- panel query
  execution stays client-side, reusing the existing /query endpoint.
- New /alerting service: rule/target CRUD, a ticker-driven evaluator
  (claim-then-evaluate concurrency control, transactional-outbox
  delivery, query errors and threshold zero-rows never coerced into a
  false transition) and webhook/Slack/PagerDuty delivery with
  retry/backoff. See docs/phase-3-alerting-design.md for the full
  state-machine design and the four correctness properties it
  implements.
- web: /dashboards and /alerts UIs; cli: sentryctl dashboards/alerts
  list/get/apply, seeding a future Terraform provider's JSON contract.
- hack/alert-load-test: 500 rules against real ClickHouse data, real
  measured results in docs/phase-3-runbook.md.

Five real bugs found by actually running this against a live stack
(documented in the runbook, not just fixed silently): a latent Phase 2
bug where ClickHouse rejected the timestamp format used for
earliest=/latest= queries; a "now" literal token injected into query
text; a GridStack/uPlot layout-timing race; JS's Date.parse being too
lenient to use as a timestamp-detection heuristic; a rule's "enabled"
field silently defaulting to false when omitted; and the evaluator's
claim-batch-size and worker-pool-concurrency defaulting to the same
value, causing 500 concurrently-due rules to take 125s to cycle through
instead of the configured 60s.

api/internal/querylang/executor/sql.go

@@ -164,22 +164,41 @@ func buildWhereClause(plan *ir.Plan, recordIDFilter []string) string {
 
 	if plan.TimeRange != nil {
 		if !plan.TimeRange.From.IsZero() {
-			conds = append(conds, "`timestamp` >= "+quoteLiteral(plan.TimeRange.From.UTC().Format(time.RFC3339Nano)))
+			conds = append(conds, "`timestamp` >= "+quoteLiteral(formatClickHouseDateTime64(plan.TimeRange.From)))
 		}
 		if !plan.TimeRange.To.IsZero() {
-			conds = append(conds, "`timestamp` <= "+quoteLiteral(plan.TimeRange.To.UTC().Format(time.RFC3339Nano)))
+			conds = append(conds, "`timestamp` <= "+quoteLiteral(formatClickHouseDateTime64(plan.TimeRange.To)))
 		}
 	}
 
 	return strings.Join(conds, " AND ")
 }
 
+// formatClickHouseDateTime64 formats t the way ClickHouse's implicit
+// string->DateTime64 CAST expects for a WHERE-clause comparison:
+// "YYYY-MM-DD HH:MM:SS[.fractional]", space-separated, no 'T'/'Z'. This
+// is a real, measured requirement, not a guess: an ISO-8601/RFC3339Nano
+// literal (e.g. "2026-08-12T20:17:40.223505479Z", what time.RFC3339Nano
+// produces) fails at query time with "code: 53, Cannot convert string
+// ... to type DateTime64(9, 'UTC')" -- ClickHouse's *implicit* cast used
+// for column-vs-literal comparisons is strict, unlike the lenient
+// parseDateTimeBestEffort used elsewhere in ClickHouse. Found by
+// actually running a dashboard panel with a relative earliest= against
+// live ClickHouse (Phase 2's own unit tests never caught this: they
+// assert against a fake SQLRunner that checks the generated SQL string,
+// not that ClickHouse accepts it, and none of Phase 2's own live-stack
+// runbook queries happened to use earliest=/latest= at all).
+func formatClickHouseDateTime64(t time.Time) string {
+	return t.UTC().Format("2006-01-02 15:04:05.999999999")
+}
+
 // buildComparisonSQL numeric-casts a non-top-level field only when the
 // compared value itself looks numeric -- `status>=500` casts (numeric
 // comparison intent), `status="unknown"` doesn't (string comparison
 // intent). Top-level fields are never cast; ClickHouse compares them
-// against a string literal natively (DateTime64 columns parse an
-// RFC3339-shaped literal, LowCardinality(String)/String compare as-is).
+// against a string literal natively (LowCardinality(String)/String
+// compare as-is; DateTime64 columns need formatClickHouseDateTime64's
+// exact literal shape, handled in buildWhereClause above, not here).
 func buildComparisonSQL(f ir.FilterPredicate) string {
 	if !topLevelFields[f.Field] && isNumericLiteral(f.Value) {
 		return "toFloat64OrZero(" + columnExpr(f.Field) + ") " + f.Op + " " + f.Value