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.

search/README.md

@@ -29,12 +29,34 @@ tracking, own failure domain — see "Offset tracking" below) even though
 it's a completely separate process/service. If Tantivy indexing lags or
 crashes, ClickHouse ingestion is completely unaffected.
 
-`api` calls `search`'s `SearchService.Search` gRPC RPC (see
-`/proto/sentry/search/v1/search.proto`) to resolve a free-text query into
-matching `record_id`s, then joins those back against ClickHouse's
-`logs.record_id` column (see `/storage/migrations/0002_add_record_id.sql`)
-to get full rows. `search` only ever returns IDs, never row data — it
-stays a pure text index, not a second copy of the row.
+`api` (or, for a multi-tenant deployment, `enterprise-api` — see
+`/enterprise/README.md`) calls `search`'s `SearchService.Search` gRPC RPC
+(see `/proto/sentry/search/v1/search.proto`) to resolve a free-text
+query into matching `record_id`s, then joins those back against
+ClickHouse's `logs.record_id` column (see
+`/storage/migrations/0002_add_record_id.sql`) to get full rows. `search`
+only ever returns IDs, never row data — it stays a pure text index, not
+a second copy of the row.
+
+## Per-tenant indices (Phase 4) — read-side only
+
+`SearchRequest.tenant_id` (empty by default) selects which index
+`src/registry.rs`'s `IndexRegistry` searches: empty resolves to the
+single default index every deployment already had; a non-empty value
+opens (on first use) a dedicated index under `TENANTS_INDEX_PATH`
+(default `/var/lib/sentry-search/tenants/<tenant_id>`, matching
+`deploy/operator`'s and `enterprise/internal/rbacstore`'s existing path
+convention). `tenant_id` is set only by a trusted server-side caller
+(`enterprise/internal/searchclient`, from the authenticated request
+identity) — never a value a browser/client controls.
+
+**This is read-side isolation only.** `consumer.rs`'s Redpanda consumer
+— the only thing that ever *writes* into an index — still only ever
+writes into the single default index, because `ingest`/the log-record
+schema itself carries no tenant concept yet. A newly-opened tenant index
+starts, and stays, empty until something upstream of this service
+becomes tenant-aware on the write side too — a real, disclosed gap, not
+an oversight; see `/docs/security/threat-model.md`.
 
 ## Offset tracking: why this isn't a Kafka consumer group
 
@@ -74,7 +96,8 @@ Environment variables (see `src/config.rs`):
 | `REDPANDA_BROKERS` | `localhost:9092` | Comma-separated broker list |
 | `REDPANDA_TOPIC` | `sentry.logs.raw` | Must match `/ingest`'s topic |
 | `REDPANDA_TOPIC_PARTITIONS` | `6` | Must match what `/transport/provision-topics.sh` created |
-| `INDEX_PATH` | `/var/lib/sentry-search/index` | Tantivy index directory |
+| `INDEX_PATH` | `/var/lib/sentry-search/index` | Default (non-tenant) Tantivy index directory |
+| `TENANTS_INDEX_PATH` | `/var/lib/sentry-search/tenants` | Per-tenant index directories live under here, one subdirectory per tenant_id (Phase 4) |
 | `OFFSETS_PATH` | `/var/lib/sentry-search/offsets.json` | Offset tracking file |
 | `COMMIT_INTERVAL_MS` | `2000` | How often buffered writes become searchable |
 
@@ -89,7 +112,13 @@ cargo test
 `index.rs`'s tests run against a real (temp-directory) Tantivy index —
 no external service needed, unlike ClickHouse. They cover the
 delete-then-add idempotency, phrase queries, result limits, and the
-before-commit/after-commit visibility boundary. `consumer.rs` (the
+before-commit/after-commit visibility boundary. `registry.rs`'s tests
+are the same shape and cover the actual adversarial claim: real per-
+tenant indices, real documents, and a search scoped to one tenant
+returning zero results for another tenant's matching document
+(`tenant_index_is_isolated_from_default_and_other_tenants`) — all of
+this, unlike almost everything else in Phase 4, was genuinely run in
+the environment this was built in, not just written. `consumer.rs` (the
 rskafka wiring) is not unit-tested — that needs a real Redpanda, same
 category of gap as `/ingest`'s `kafka.Reader`/`kafka.Writer` wiring, and
 is exercised by the docker-compose end-to-end flow instead.