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.

enterprise/README.md

@@ -64,6 +64,19 @@ section for exactly what "not yet run" means here and why. Don't read
   verification, no live database or Docker needed) and every test
   passes. Not yet tried against a real external IdP or a running
   `enterprise-auth` container.
+- `internal/searchclient`: the Tantivy-side sibling of `chrunner` --
+  implements `api/querylang/executor.SearchClient`, resolving
+  `SearchRequest.tenant_id` (new field, `proto/sentry/search/v1/
+  search.proto`) from the authenticated request identity, same
+  fail-closed shape as `chrunner.Registry.RunSQL`. Paired with
+  `search/src/registry.rs`'s `IndexRegistry` (Rust, opens a per-tenant
+  Tantivy index on demand). **Both genuinely verified** -- unlike the
+  ClickHouse pieces, Tantivy is an embedded library, so the isolation
+  probe (three tenants, shared search term, scoped search returns only
+  that tenant's document) actually ran: `search`'s
+  `cargo test`/`cargo clippy --all-targets -- -D warnings` and this
+  package's `go test` both pass clean, no Docker or live database
+  needed for either.
 - `cmd/enterprise-api`: a second binary (alongside `api/cmd/api`,
   unchanged) importing *both* `api`'s handler packages and the
   tenant-aware implementations above -- see its own doc comment for why
@@ -86,15 +99,19 @@ silently left out:
   `metadata/migrations/0024`; no caller reads per-resource grants
   yet -- `dashboards`' handler enforces tenant-baseline role only, not
   the matrix's "(own/granted)" qualifier).
-- `internal/searchclient` (the Tantivy-side sibling of `chrunner`) --
-  `enterprise-api` shares the single, un-tenant-scoped Tantivy index
-  every deployment does today (`api/searchclient.Dial`, unchanged). See
+- **Ingest tenant-awareness, for either storage engine** -- `chrunner`/
+  `searchclient` prove read isolation given tenant-scoped data exists,
+  but nothing writes it: every record `ingest` produces still lands in
+  the single shared ClickHouse database and the single shared Tantivy
+  index. A newly-provisioned tenant's storage is real and isolated, and
+  permanently empty. Undesigned, not just unbuilt -- see
   `/docs/security/threat-model.md`.
 - Any deployment-topology mechanism that actually routes traffic to
   `enterprise-api` instead of `api` -- both binaries exist,
   `docker-compose.yml` includes `enterprise-api` available but not
   wired into `web`'s default base URL, and the Helm chart has no
-  service for it at all yet.
+  service for it at all yet. **This is now the single largest gap** --
+  both storage engines' isolation mechanisms themselves are built.
 
 ## Package layout
 
@@ -110,14 +127,15 @@ internal/loginhandler/       GET /auth/oidc/login, GET /auth/oidc/callback -- th
 internal/rbacstore/          users/tenants/tenant_memberships/data_sources CRUD (pgx against sentry_metadata)
 internal/tenantprovision/     real ClickHouse CREATE DATABASE/USER/GRANT
 internal/chrunner/             tenant-scoped api/querylang/executor.SQLRunner
+internal/searchclient/          tenant-scoped api/querylang/executor.SearchClient
 internal/audit/            append-only, hash-chained query audit log, plus the
                             api/queryapi.AuditLogger adapter (queryapi_adapter.go)
 internal/apiconfig/       enterprise-api's own env-var config
 internal/config/          enterprise-auth's env-var config
 ```
 
-Future additions: `internal/searchclient`, the OIDC/SAML login/callback
-HTTP handlers, `dashboard_permissions` CRUD, and real deployment-topology
+Future additions: SAML's login handler, `dashboard_permissions` CRUD,
+ingest tenant-awareness (undesigned), and real deployment-topology
 wiring for `enterprise-api` -- see "Status" above.
 
 ## Why OIDC and SAML aren't hand-rolled