Phase 4: Helm chart enforces api vs enterprise-api, closing the deployment-topology gap

deploy/helm/sentry/templates/api.yaml and the new enterprise-api.yaml
are mutually exclusive, gated on opposite sides of the same
enterprise.enabled flag -- exactly one renders, both as a Deployment+
Service named {{ .Release.Name }}-api on port 8080, so every consumer
(alerting's API_QUERY_URL, web's build args) needs zero conditional
logic of its own. This is the concrete fix for what the threat model
named as the single largest remaining gap once both storage engines'
isolation mechanisms were built: previously nothing forced or flagged
whether a deployment ran the tenant-isolated binary. Now the same flag
that turns on RBAC/audit/SSO also chooses the query binary.

Verified by parsing (not eyeballing) helm template's rendered output
under both value sets: exactly one sentry-api Deployment/Service either
way, with the right image, and kubeconform -strict clean against the
real Kubernetes 1.31 schema. Not applied to a live cluster (still no
cluster in this environment) -- docker-compose.yml also still runs
plain api unconditionally, so this enforcement is Helm-only for now.

Updated the threat model, architecture doc, CLAUDE.md, and deploy/
READMEs to reflect this and to name what's left: ingest has no tenant
concept for either storage engine (undesigned), and the Tenant CRD
(deploy/operator) and enterprise-api -provision-tenant are still two
separate, unreconciled provisioning mechanisms.

deploy/helm/sentry/README.md

@@ -1,7 +1,7 @@
 # deploy/helm/sentry
 
 A Helm chart covering every `docker-compose.yml` service (Redpanda,
-ClickHouse, Postgres, ingest, search, api, alerting, web) plus, when
+ClickHouse, Postgres, ingest, search, alerting, web) plus, when
 `enterprise.enabled: true`: enterprise-auth, the `deploy/operator`
 tenant-operator, and `Tenant` CRs from `values.tenants`. See
 `/deploy/README.md` for what "multi-tenant-aware" does and doesn't mean
@@ -12,6 +12,27 @@ This chart never builds images -- push every image its `values.yaml`
 references to a registry the cluster can pull from first, same division
 of labor as `docker compose build` vs. `docker compose up`.
 
+## `api` vs `enterprise-api`: one Deployment, chosen by `enterprise.enabled`
+
+`templates/api.yaml` and `templates/enterprise-api.yaml` are mutually
+exclusive, gated on opposite sides of the same `enterprise.enabled` flag
+-- exactly one of them ever renders, both under the same
+`{{ .Release.Name }}-api` Service name and port 8080. This is the fix
+for what `/docs/security/threat-model.md` named as Phase 4's single
+largest remaining gap once both storage engines' isolation mechanisms
+were built: previously nothing forced or even flagged whether a
+deployment ran the tenant-isolated binary. Now it's not a second knob to
+remember -- the same flag that turns on RBAC/audit/SSO also swaps which
+query binary actually serves `/query` and `/dashboards` traffic. Every
+consumer (`alerting`'s `API_QUERY_URL`, `web`'s build args) needs zero
+conditional logic of its own, since both variants answer on the same
+name/port.
+
+`enterprise-api` starts with an empty tenant set until
+`-provision-tenant` has been run for at least one tenant (see
+`/enterprise/README.md`) -- until then it's up and healthy, but every
+`/query` request correctly fails closed with no tenant to route to.
+
 ## Startup ordering
 
 `docker-compose.yml` uses `depends_on: condition: service_healthy` /
@@ -56,10 +77,15 @@ kubectl get secret sentry-tenant-acme-clickhouse sentry-tenant-globex-clickhouse
 
 This proves the K8s-side half of Phase 4's "two tenants... with their
 own users, roles, dashboards" exit criteria (`/CLAUDE.md`) -- a real
-per-tenant credential Secret exists for each. It does **not** by itself
-give either tenant a working login, dashboard, or ClickHouse database:
-those need the OIDC/SAML login handlers, `internal/tenantprovision`, and
-`internal/rbacstore` wiring the Phase 4 task 5 summary names as deferred.
+per-tenant credential Secret exists for each, generated by
+`deploy/operator`'s `Tenant` controller. It does **not** by itself give
+either tenant a working ClickHouse database or Tantivy index -- that
+needs `enterprise-api -provision-tenant=<id>` (a separate, deliberately
+manual operator action; the `Tenant` CRD and `-provision-tenant` are two
+independent mechanisms today, not yet unified -- see
+`/enterprise/README.md`), and OIDC login (built, but still needs a
+manual `tenant_memberships` row -- see `/docs/phase-4-runbook.md` §3a)
+before a human can actually query as that tenant.
 
 ## `web`'s image needs rebuilding per environment