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.

alerting/internal/delivery/pagerduty.go

@@ -0,0 +1,57 @@
+package delivery
+
+import (
+	"encoding/json"
+	"fmt"
+
+	"github.com/sentry/sentry/alerting/internal/notifystore"
+)
+
+// pagerDutyPayload is PagerDuty's Events API v2 shape. routing_key comes
+// from the target's `secret` field -- PagerDuty calls this an
+// "integration key," not a delivery credential in the auth sense, but
+// it's stored in the same plaintext `secret` column as any other
+// target's credential (see /docs/phase-3-alerting-design.md's "Known
+// gaps").
+type pagerDutyPayload struct {
+	RoutingKey  string                `json:"routing_key"`
+	EventAction string                `json:"event_action"` // "trigger" | "resolve"
+	DedupKey    string                `json:"dedup_key"`    // rule_id -- lets PagerDuty correlate trigger/resolve as one incident
+	Payload     pagerDutyEventPayload `json:"payload"`
+}
+
+type pagerDutyEventPayload struct {
+	Summary  string `json:"summary"`
+	Source   string `json:"source"`
+	Severity string `json:"severity"`
+}
+
+func buildPagerDutyPayload(target notifystore.Target, event Event) ([]byte, error) {
+	action := "trigger"
+	severity := "critical"
+	if event.EventType == "resolved" {
+		action = "resolve"
+		severity = "info"
+	}
+
+	var routingKey string
+	if target.Secret != nil {
+		routingKey = *target.Secret
+	}
+
+	summary := fmt.Sprintf("%s: %s", event.RuleName, event.EventType)
+	if event.Value != nil && event.ThresholdValue != nil {
+		summary = fmt.Sprintf("%s (value %.4g %s %.4g)", summary, *event.Value, comparatorSymbol(event.Comparator), *event.ThresholdValue)
+	}
+
+	return json.Marshal(pagerDutyPayload{
+		RoutingKey:  routingKey,
+		EventAction: action,
+		DedupKey:    event.RuleID,
+		Payload: pagerDutyEventPayload{
+			Summary:  summary,
+			Source:   "sentry",
+			Severity: severity,
+		},
+	})
+}