Build per-tenant ClickHouse write-routing for ingest (Tantivy still deferred)

ingest tags every record with a tenant_id Kafka header (built previously),
but nothing consumed it to actually route the write. This closes that for
ClickHouse: enterprise/cmd/enterprise-ingest (a second binary, mirroring
enterprise-api) reuses ingest/consumer's own flush loop unchanged, with
enterprise/internal/chwriter.Registry -- a per-tenant clickhousewriter.Writer
registry -- swapped in as the writer. A batch pulled from the single shared
Redpanda topic can mix records from many tenants, so WriteBatch groups by
TenantID and dispatches each group to its own tenant's connection, fail-
closed on an empty or unrecognized tenant_id.

ingest/consumer and ingest/clickhousewriter move out of internal/ (same
reason api/internal/* moved earlier this phase: enterprise/ can't import
anything under another module's internal/). Their New() constructors now
take small local Config structs instead of ingest/internal/config types,
so enterprise/ doesn't need that import either.

Building this surfaced a real bug: tenantprovision.ProvisionClickHouse
only granted SELECT on a tenant's ClickHouse user, correct for chrunner's
read-only use but not enough for chwriter reusing the same credential to
write -- every real per-tenant write would have failed closed with a
permission error. Fixed by widening the grant to SELECT, INSERT; no
cross-tenant boundary is crossed by also allowing INSERT within a
tenant's own database.

Helm gates enterprise-ingest's Deployment on the same
ingest.requireTenantCredential flag that already gates tag validation --
write-routing is meaningless without tagging already being required, so
they're one decision, not two. docker-compose.yml's version is a
disclosed, weaker approximation: it can't achieve Helm's genuine
-mode=server/-mode=consumer split, so with the enterprise profile active
both ingest and enterprise-ingest independently consume every message
via different consumer groups -- harmless duplication for local
verification only.

Not built: Tantivy's independent Redpanda consumer (search/src/consumer.rs)
still doesn't read the tenant_id header at all -- every record still lands
in the one shared index regardless of tenant. Not run: the live-ClickHouse-
gated tests (chwriter's cross-tenant routing test, tenantprovision's INSERT
regression test) -- no Docker/database access in this environment; they're
correct Go that has never executed, disclosed as such in docs/security/
threat-model.md and docs/phase-4-runbook.md §14.

enterprise/internal/tenantprovision/tenantprovision.go

@@ -59,8 +59,16 @@ func New(admin driver.Conn) *Provisioner {
 }
 
 // ProvisionClickHouse creates tenantID's database and a fresh user for
-// it, granted SELECT on exactly that database and nothing else.
-// Database creation is idempotent (CREATE DATABASE IF NOT EXISTS --
+// it, granted SELECT and INSERT on exactly that database and nothing
+// else -- one credential covers both enterprise/internal/chrunner's
+// query path and enterprise/internal/chwriter's ingest-write path
+// (found while building chwriter: the grant here originally covered
+// SELECT only, which would have made every real per-tenant ClickHouse
+// write fail with a permission error -- there's no cross-tenant
+// boundary crossed by also granting INSERT within a tenant's own
+// database, so a single credential for both directions is the simpler,
+// still-correctly-scoped choice over provisioning a second write-only
+// credential). Database creation is idempotent (CREATE DATABASE IF NOT EXISTS --
 // harmless to repeat). User creation deliberately is NOT idempotent
 // (plain CREATE USER, no IF NOT EXISTS): ClickHouse has no way to read
 // back an existing user's password, so silently succeeding on a second
@@ -108,8 +116,8 @@ func (p *Provisioner) ProvisionClickHouse(ctx context.Context, tenantID string)
 		return Credentials{}, fmt.Errorf("tenantprovision: creating user (already provisioned? this call is not safe to retry): %w", err)
 	}
 
-	if err := p.admin.Exec(ctx, fmt.Sprintf("GRANT SELECT ON `%s`.* TO `%s`", database, username)); err != nil {
-		return Credentials{}, fmt.Errorf("tenantprovision: granting select: %w", err)
+	if err := p.admin.Exec(ctx, fmt.Sprintf("GRANT SELECT, INSERT ON `%s`.* TO `%s`", database, username)); err != nil {
+		return Credentials{}, fmt.Errorf("tenantprovision: granting select/insert: %w", err)
 	}
 
 	return Credentials{Username: username, Password: password}, nil

enterprise/internal/tenantprovision/tenantprovision_test.go

@@ -80,6 +80,41 @@ func TestProvisionClickHouseCreatesUsableTenantConnection(t *testing.T) {
 	}
 }
 
+// TestProvisionedUserCanInsertIntoOwnDatabase is the regression test for
+// a real bug found while building enterprise/internal/chwriter: this
+// credential is also the one chwriter.Registry uses to write ingested
+// records, so it must be able to INSERT into its own database, not just
+// SELECT from it -- the grant originally only covered SELECT, which
+// would have made every real per-tenant ClickHouse write fail with a
+// permission error.
+func TestProvisionedUserCanInsertIntoOwnDatabase(t *testing.T) {
+	admin := testAdminConn(t)
+	p := New(admin)
+	tenantID := testTenantID()
+	ctx := context.Background()
+
+	creds, err := p.ProvisionClickHouse(ctx, tenantID)
+	if err != nil {
+		t.Fatalf("ProvisionClickHouse: %v", err)
+	}
+	if err := admin.Exec(ctx, fmt.Sprintf("CREATE TABLE `%s`.marker (id UInt8) ENGINE = Memory", tenantID)); err != nil {
+		t.Fatalf("creating marker table: %v", err)
+	}
+
+	tenantConn, err := clickhouse.Open(&clickhouse.Options{
+		Addr: []string{os.Getenv("TENANTPROVISION_TEST_CLICKHOUSE_ADDR")},
+		Auth: clickhouse.Auth{Database: tenantID, Username: creds.Username, Password: creds.Password},
+	})
+	if err != nil {
+		t.Fatalf("opening tenant connection: %v", err)
+	}
+	defer tenantConn.Close()
+
+	if err := tenantConn.Exec(ctx, "INSERT INTO marker VALUES (42)"); err != nil {
+		t.Fatalf("INSERT as the provisioned tenant user into its own database: %v", err)
+	}
+}
+
 // TestProvisionedUserCannotReadOtherTenantDatabase is one of the four
 // adversarial probes /docs/phase-4-isolation-design.md's verification
 // plan names for Phase 4 task 8 (see api/queryapi/