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.

enterprise/internal/authhandler/authhandler.go

@@ -1,6 +1,6 @@
 // Package authhandler implements enterprise-auth's POST /internal/authorize
 // endpoint -- the HTTP side of the "network boundary, not import boundary"
-// pattern api/internal/authz.HTTPAuthorizer calls into (see that package's
+// pattern api/authz.HTTPAuthorizer calls into (see that package's
 // doc comment). It resolves a caller's credentials (session cookie or
 // service-token Bearer header) to an identity, using session.Manager for
 // both -- a human session and /alerting's service token are both just
@@ -18,7 +18,7 @@ import (
 	"github.com/sentry/sentry/enterprise/internal/session"
 )
 
-// SessionCookieName matches the name api/internal/authz.HTTPAuthorizer's
+// SessionCookieName matches the name api/authz.HTTPAuthorizer's
 // tests and doc comments already assume ("sentry_session").
 const SessionCookieName = "sentry_session"