Phase 4: real Tantivy per-tenant isolation (search/src/registry.rs, enterprise/internal/searchclient)

Closes the last named "isolation mechanism" gap: search.proto gains a
tenant_id field on SearchRequest; search/src/registry.rs's IndexRegistry
resolves it to an on-demand-opened, per-tenant Tantivy index (empty
tenant_id keeps today's single default index, so this is purely
additive); enterprise/internal/searchclient sets that field from the
authenticated request identity in ctx, mirroring chrunner's exact
fail-closed "never a parameter" shape. Wired into enterprise-api in
place of the shared api/searchclient.

Unlike the ClickHouse pieces from the previous two commits, this one is
genuinely verified end to end in this environment: Tantivy is an
embedded library, not a networked service, so both the Rust index
registry (cargo test, cargo clippy --all-targets -- -D warnings, both
clean) and the Go client (a real in-process gRPC server) could actually
run. registry.rs's tenant_index_is_isolated_from_default_and_other_tenants
seeds three real indices with the same term and confirms a tenant-scoped
search returns only that tenant's document -- item 3 of the isolation
design doc's verification plan, closed for real, not just written.

With both ClickHouse and Tantivy isolation now built, the single largest
remaining gap is no longer a missing mechanism: it's that nothing forces
or flags whether a deployment actually runs enterprise-api instead of
plain api, and that ingest itself has no tenant concept for either
storage engine (every record still lands in the one shared database/
index no matter what -- undesigned, not just unbuilt). Updated the
threat model, architecture doc, CLAUDE.md, and both READMEs accordingly.

api/queryapi/tenant_isolation_gap_test.go

@@ -3,46 +3,35 @@
 // "Verification plan for this design specifically" section names for
 // Phase 4 task 8 have a permanent, grep-able home in the test tree.
 //
-// Item 1 (fully-qualified cross-tenant raw SQL) is no longer blocked:
-// enterprise/internal/tenantprovision and enterprise/internal/chrunner
-// now exist, and both have real, passing (when run against a live
-// ClickHouse) tests for exactly this probe --
-// enterprise/internal/tenantprovision/tenantprovision_test.go's
-// TestProvisionedUserCannotReadOtherTenantDatabase (at the raw
-// ClickHouse-user layer) and enterprise/internal/chrunner/
-// chrunner_test.go's TestRegistryTenantCannotReadOtherTenantEvenViaRawSQL
-// (through the actual query-execution code path api/queryapi.Handler
-// calls in production, when fronted by enterprise/cmd/enterprise-api
-// instead of plain api/cmd/api). Nothing to assert here anymore for
-// item 1 -- see those two tests instead.
+// Three of the four are no longer blocked:
 //
-// Items 2-4 remain blocked, for the reasons each Skip below states.
-// Note the scope boundary this leaves: even with chrunner wired in,
-// there is still exactly one shared Tantivy index for every tenant
-// (enterprise/internal/searchclient, the Tantivy-side equivalent of
-// chrunner, is unbuilt) -- see /docs/security/threat-model.md.
+//   - Item 1 (fully-qualified cross-tenant raw SQL):
+//     enterprise/internal/tenantprovision/tenantprovision_test.go's
+//     TestProvisionedUserCannotReadOtherTenantDatabase (raw ClickHouse-user
+//     layer) and enterprise/internal/chrunner/chrunner_test.go's
+//     TestRegistryTenantCannotReadOtherTenantEvenViaRawSQL (the actual
+//     query-execution code path, via enterprise/cmd/enterprise-api).
+//   - Item 2 (system.query_log/system.tables/SHOW DATABASES):
+//     enterprise/internal/tenantprovision/tenantprovision_test.go's
+//     TestProvisionedUserCannotReadSystemTables.
+//   - Item 3 (Tantivy cross-tenant search): search/src/registry.rs's
+//     tenant_index_is_isolated_from_default_and_other_tenants (Rust, the
+//     actual per-tenant index registry) and enterprise/internal/
+//     searchclient/searchclient_test.go (the Go client that resolves
+//     tenant_id from request identity, wire-level verified against a
+//     real in-process gRPC server).
+//
+// Item 4 remains blocked, for the reason its Skip below states. Note the
+// scope boundary all three closed items share: they prove *read*
+// isolation given tenant-scoped data exists -- they do not prove
+// ingest/write-path tenancy, which doesn't exist yet (every record
+// ingest produces lands in the single shared ClickHouse database and
+// Tantivy index regardless of tenant) -- see
+// /docs/security/threat-model.md.
 package queryapi
 
 import "testing"
 
-func TestAdversarial_ClickHouseUserCannotReadSystemTables(t *testing.T) {
-	t.Skip("BLOCKED on enterprise/internal/tenantprovision: needs a real per-tenant " +
-		"ClickHouse user to attempt `SELECT * FROM system.query_log`, " +
-		"`system.tables`, `SHOW DATABASES` against, and confirm system.* " +
-		"access was actually revoked (not just assumed from ClickHouse's " +
-		"default template -- task 2's finding was that this is " +
-		"version-dependent and must be checked live, not read from docs). " +
-		"See /docs/phase-4-isolation-design.md's verification plan, item 2.")
-}
-
-func TestAdversarial_TantivySearchExcludesOtherTenantsMatchingResults(t *testing.T) {
-	t.Skip("BLOCKED on enterprise/internal/searchclient: needs two real " +
-		"per-tenant Tantivy indices, one seeded with a term, to confirm a " +
-		"search scoped to the other tenant returns zero hits for that term " +
-		"even though the term exists in the other index. See " +
-		"/docs/phase-4-isolation-design.md's verification plan, item 3.")
-}
-
 func TestAdversarial_EvaluatorTickMidProvisioningIsRefusedNotServed(t *testing.T) {
 	t.Skip("BLOCKED on enterprise/internal/tenantprovision's ordered " +
 		"provisioning state machine (CREATE USER -> GRANT -> mark active): " +