Phase 4: SSO scaffolding, RBAC enforcement, tenant-scoped dashboards, audit logging, K8s deployment

RBAC (api/internal/authz) is live on /query and /dashboards, backed by a
new enterprise/ module (session issuance, audit logging, RBAC storage,
OIDC/SAML protocol wiring) that core never imports -- only calls over
HTTP. Found and fixed a real cross-tenant vulnerability in dashboards
(no tenant_id filtering at all) while writing the threat model doc.

Two things are explicitly NOT done, documented rather than hidden:
tenant isolation for log data itself (/query still shares one ClickHouse
connection and Tantivy index across every tenant -- RBAC controls who
can query, not what a query can see), and human SSO login (protocol
wiring exists, no HTTP handler calls it yet). See
docs/security/threat-model.md and docs/phase-4-runbook.md.

Also adds deploy/ (Go Operator + Helm chart, validated offline only --
no cluster was reachable in this environment).

metadata/README.md

@@ -11,11 +11,14 @@ doesn't provide.
 
 ## Schema
 
-Six tables across two features, one shared database (`sentry_metadata`):
+Seven tables across three features, one shared database (`sentry_metadata`):
 
 - `dashboards`, `dashboard_panels` — owned by `/api` (`api/internal/dashboards`)
 - `notification_targets`, `alert_rules`, `alert_state`, `delivery_log` —
   owned by `/alerting`
+- `audit_log` — owned by `enterprise/internal/audit` (Phase 4). Unlike
+  every other table here, this one is **not** written through the shared
+  `sentry` role/pool — see "The `audit_writer` role" below.
 
 "Owned" here is a documentation convention, not a technical boundary —
 both services connect to the same Postgres instance/database, each with
@@ -24,6 +27,43 @@ shared across service `internal/` trees for this, matching the existing
 repo convention that only `/proto` is shared code (and even that isn't
 shared logic, just generated bindings).
 
+## The `audit_writer` role: a second, more restricted credential
+
+`audit_log` is append-only by design (see
+`/docs/phase-4-isolation-design.md`'s audit-logging section) — a
+compliance requirement, not just a convention, so it's backed by two
+independent defenses, both verified against a live Postgres, not just
+written:
+
+1. A dedicated `audit_writer` Postgres role (`migrations/0012`-`0014`)
+   with **only** `INSERT`/`SELECT` grants on `audit_log` — no
+   `UPDATE`/`DELETE`/`TRUNCATE`, ever. `enterprise/internal/audit.Store`
+   connects using this role's credentials via its **own** `pgxpool.Pool`,
+   never the shared `sentry` pool `api`/`alerting`'s other stores use —
+   reusing the shared pool for audit writes would give audit_log's
+   application-level credential the same `UPDATE`/`DELETE` grants every
+   other metadata table has, silently defeating the whole point.
+2. A `BEFORE UPDATE OR DELETE` trigger (`migrations/0015`-`0016`) that
+   rejects the operation for **any** role, including the table owner
+   (`sentry`) — confirmed live: even `sentry` needs to explicitly
+   `ALTER TABLE audit_log DISABLE TRIGGER audit_log_immutable` (a
+   privileged, distinct-from-normal-access operation) before it can
+   modify a row. This is redundant defense-in-depth independent of the
+   grant, protecting against a future migration accidentally re-granting
+   `UPDATE` to `audit_writer`.
+
+`AUDIT_WRITER_PASSWORD` (default `audit-writer-dev-only`, matching every
+other dev-only credential in this repo) sets the role's password at
+creation time via `psql -v audit_writer_password=...` substitution in
+`migrate.sh` — **not** hardcoded in the migration SQL file itself. One
+real gotcha found while building this: psql's `:'var'` substitution does
+**not** apply inside a `DO $$ ... $$` dollar-quoted block (by design, so
+client-side substitution can't corrupt a function/procedure body) — the
+role-creation migration is a plain `CREATE ROLE`, not wrapped in an
+`IF NOT EXISTS` check, relying on `schema_migrations` tracking for
+idempotency instead (the same pattern Phase 1's non-idempotent
+`ALTER TABLE ... ADD COLUMN` migration in `/storage` already used).
+
 ## Migration tooling: mirrors `/storage/migrate.sh`, not a framework
 
 Same reasoning as `/storage/README.md`: pulling in `golang-migrate` for
@@ -52,6 +92,7 @@ Environment variables `migrate.sh` reads (all optional except
 | `POSTGRES_USER` | `sentry` |
 | `POSTGRES_PASSWORD` | (empty — must be set) |
 | `POSTGRES_DATABASE` | `sentry_metadata` |
+| `AUDIT_WRITER_PASSWORD` | `audit-writer-dev-only` |
 
 The database itself isn't created by `migrate.sh` — the `postgres:16-alpine`
 image auto-creates `POSTGRES_DB` on first startup, unlike ClickHouse where