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.

docs/architecture.md

@@ -147,15 +147,22 @@ escape hatch is opaque to any compiler-injected filter.
   `chrunner`/`searchclient` becomes tenant-aware on the write side,
   which is undesigned, not merely unbuilt.
 - `deploy/operator`'s `Tenant` CRD still manages only the K8s-side
-  artifact (a credential Secret); the Helm chart has no service
-  definition for `enterprise-api` yet.
+  artifact (a credential Secret); it doesn't call
+  `enterprise-api -provision-tenant` or otherwise trigger ClickHouse-side
+  provisioning. The two mechanisms are independent today, not reconciled
+  into one state machine.
 
-The deployment-topology gap — giving the system an actual way to route
-traffic to `enterprise-api` instead of `api` (a Helm service, or at
-minimum a documented, enforced convention) — is now the single largest
-remaining gap between this system and the isolation model it was
-designed to have; both storage engines' connection/index-layer
-mechanisms themselves are built.
+**The deployment-topology gap is closed for the Helm chart**: `deploy/
+helm/sentry/templates/api.yaml`/`enterprise-api.yaml` are mutually
+exclusive on `enterprise.enabled`, rendering to the same Service name
+and port either way, so a Helm-deployed cluster can't accidentally run
+the wrong binary — the same flag that turns on RBAC/audit/SSO now also
+chooses the query binary. `docker-compose.yml` still runs plain `api`
+unconditionally, so this enforcement doesn't yet extend to local/dev.
+With both storage engines' connection/index-layer mechanisms built and
+deployment topology enforced at the Helm layer, the largest remaining
+gaps are ingest's lack of tenant-awareness (undesigned) and unifying the
+`Tenant` CRD with `-provision-tenant` into one provisioning flow.
 
 ## Licensing boundary