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/executor_test.go

@@ -300,10 +300,34 @@ func TestBuildSQLTimeRange(t *testing.T) {
 	to := mustParseTime(t, "2026-08-14T01:00:00Z")
 	plan := &ir.Plan{TimeRange: &ir.TimeRange{From: from, To: to}}
 	sql := buildSQL(plan, nil)
-	if !strings.Contains(sql, "`timestamp` >= '2026-08-14T00:00:00Z'") {
+	// Space-separated, no 'T'/'Z' -- ClickHouse's implicit string->DateTime64
+	// cast for a column-vs-literal comparison is strict and rejects
+	// RFC3339/ISO-8601 shaped literals ("code: 53, Cannot convert string...
+	// to type DateTime64(9, 'UTC')"), confirmed by actually running a
+	// dashboard panel with earliest= against live ClickHouse -- this test
+	// previously asserted the RFC3339 shape that ClickHouse rejects, which
+	// is exactly how the bug went unnoticed: nothing here ever executed the
+	// SQL against a real database.
+	if !strings.Contains(sql, "`timestamp` >= '2026-08-14 00:00:00'") {
 		t.Fatalf("missing From bound: %s", sql)
 	}
-	if !strings.Contains(sql, "`timestamp` <= '2026-08-14T01:00:00Z'") {
+	if !strings.Contains(sql, "`timestamp` <= '2026-08-14 01:00:00'") {
 		t.Fatalf("missing To bound: %s", sql)
 	}
 }
+
+func TestFormatClickHouseDateTime64OmitsTrailingZeroFraction(t *testing.T) {
+	// time.Time's default zero-value fractional seconds must not leave a
+	// stray "." with nothing after it -- Format's `.999999999` verb
+	// already handles this (trims to nothing when the fraction is zero),
+	// but it's worth pinning down given how easy the RFC3339Nano mistake
+	// was to miss in the first place.
+	got := formatClickHouseDateTime64(mustParseTime(t, "2026-08-14T00:00:00Z"))
+	if got != "2026-08-14 00:00:00" {
+		t.Fatalf("got %q, want no trailing fractional-seconds dot", got)
+	}
+	got = formatClickHouseDateTime64(mustParseTime(t, "2026-08-14T00:00:00.223505479Z"))
+	if got != "2026-08-14 00:00:00.223505479" {
+		t.Fatalf("got %q", got)
+	}
+}