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.

cli/README.md

@@ -26,9 +26,35 @@ auto-detection, same optional override the HTTP API itself exposes.
 Prints a table by default (stdlib `text/tabwriter`, no new dependency);
 `--json` prints the raw `{columns, rows}` response instead.
 
-No CLI framework (cobra/urfave-cli/etc.) — two commands don't need one,
-and stdlib `os.Args` handling is boring enough not to need a dependency.
-Revisit once there's a real command tree to justify one.
+```sh
+sentryctl dashboards list
+sentryctl dashboards get <id>
+sentryctl dashboards apply dashboard.json    # imports a dashboard exported via the web UI's "Export JSON" button
+
+sentryctl alerts list
+sentryctl alerts get <id>
+sentryctl alerts apply rule.json             # creates a rule from a JSON file shaped like POST /rules's body
+```
+
+`dashboards` talks to `/api` (`--api`, same override as `query`/`ping`).
+`alerts` talks to `/alerting`, a separate service with its own base URL
+(`--alerting-api`, or `$SENTRYCTL_ALERTING_API_URL`, default
+`http://localhost:8081`) — see `/docs/phase-3-alerting-design.md`'s
+component boundary for why alerting isn't just another `/api` route.
+`apply` in both cases sends the file's JSON as-is to the corresponding
+create/import endpoint — no reshaping, since the file's shape already
+matches what the endpoint expects (the same JSON the web UI's export
+button downloads, or the same shape `GET /rules/{id}` returns). This is
+deliberately the seed of a future Terraform provider: one JSON contract,
+multiple callers (web export, CLI apply, eventually a provider), not
+three different formats to keep in sync.
+
+No CLI framework (cobra/urfave-cli/etc.) — six commands split across a
+few files (`cmd_ping.go`, `cmd_query.go`, `cmd_dashboards.go`,
+`cmd_alerts.go`) is still boring enough not to need one; stdlib
+`os.Args` handling plus a hand-rolled `switch` in `main.go` covers it.
+Revisit once there's a real command tree (nested subcommands, nontrivial
+flag parsing) to justify a dependency.
 
 ## Building & testing