Phase 4: real per-tenant ClickHouse isolation via a new enterprise-api binary

Closes the threat model's headline finding for the SQL query path:
enterprise/internal/tenantprovision does real CREATE DATABASE/USER/GRANT
against ClickHouse, and enterprise/internal/chrunner is a per-tenant
connection registry implementing api's SQLRunner interface, resolving
the tenant from the authenticated request identity -- never a
caller-suppliable parameter. Both are wired into a new binary,
enterprise/cmd/enterprise-api, alongside the unchanged single-tenant
api/cmd/api, since AGPL core can never import enterprise/ and Go's own
internal/ package visibility rules meant enterprise/ couldn't implement
core's SQLRunner interface without importing the package that defines
it. That required moving api/internal/{authz,queryapi,dashboards,
querylang/executor,searchclient,httpserver} out of internal/ -- the
minimal set enterprise-api needs to import; querylang's compiler
internals (planner/lexer/parser/ast/ir) and api's own config stay
internal, since nothing outside api needs them directly.

Also finally wires enterprise/internal/audit into queryapi.AuditLogger
(nil since Phase 4 task 4) via a new adapter, and adds live-ClickHouse
integration tests for two of the four adversarial probes named in
docs/phase-4-isolation-design.md's verification plan.

Corrected several overclaims in the docs while writing this up: an
earlier claim that rbacstore's CRUD was "verified against a live
Postgres" was never actually true in this environment (only
internal/audit was, earlier in this phase, before Docker access was
lost) -- threat-model.md, phase-4-runbook.md, CLAUDE.md, and
enterprise/README.md all now distinguish "a real integration test
exists" from "this was confirmed against a live database."

Still not built: Tantivy/free-text tenant isolation
(enterprise/internal/searchclient), and any deployment-topology
mechanism that actually routes traffic to enterprise-api instead of
plain api -- both binaries exist side by side today with nothing
enforcing or flagging which one a deployment runs.

CLAUDE.md

@@ -140,18 +140,29 @@ Non-goals for this phase (same discipline as every phase so far):
 
 ## What "done" looks like for Phase 4
 
-**Status: in progress, not shipped.** Through task 8: RBAC enforcement
-(`api/internal/authz`), the `alerting`↔`api` service-identity credential,
-tenant-scoped dashboards, and append-only audit logging are built and
-tested (including live-Postgres verification for audit logging and
-rbacstore). The two items this phase's exit criteria below actually
-hinge on are **not** built: SSO login (OIDC/SAML protocol wiring exists;
-no HTTP login handler calls it) and — the highest-risk one — tenant
-isolation for log data itself (every tenant's `/query` still executes
-against one shared ClickHouse connection and Tantivy index; RBAC
-controls who can query, not what a query can see). Full accounting:
-`/docs/security/threat-model.md`; step-by-step verification procedure
-(not yet run against a live cluster in this environment):
+**Status: in progress, not shipped.** RBAC enforcement (`api/authz`), the
+`alerting`↔`api` service-identity credential, tenant-scoped dashboards,
+append-only audit logging, and — since the second pass on this phase —
+real per-tenant ClickHouse provisioning and query routing
+(`enterprise/internal/tenantprovision`, `enterprise/internal/chrunner`,
+wired into a new `enterprise/cmd/enterprise-api` binary alongside plain
+`api/cmd/api`) are all built and tested — real integration tests exist
+for the ClickHouse pieces, but this environment lost Docker/database
+access partway through the phase, so only the audit-logging guarantees
+were actually confirmed against a live database; the rest is untested
+beyond "compiles, and skips cleanly when no live database is
+configured" (see `/docs/phase-4-runbook.md`'s verification-status
+section). Two things still keep this phase from being done: SSO login
+(OIDC/SAML protocol wiring exists, no
+HTTP login handler calls it), and Tantivy/free-text queries have no
+per-tenant index routing at all (`enterprise-api` closes the ClickHouse
+half of tenant isolation, not the Tantivy half) — plus a deployment gap
+worth naming explicitly: nothing yet forces or even flags whether a
+given deployment is actually running the isolated binary
+(`enterprise-api`) versus the plain single-tenant one (`api`); both
+still exist and nothing currently prevents mixing them up. Full
+accounting: `/docs/security/threat-model.md`; step-by-step verification
+procedure (not yet run against a live cluster in this environment):
 `/docs/phase-4-runbook.md`. The rest of this section describes the exit
 bar this phase is aiming at, not a completed state.