Close the last tenant-isolation adversarial probe (mid-provisioning tenants)

Phase 4 task 8's verification plan named four adversarial probes;
three were closed earlier this phase, the fourth (an evaluator tick,
or any other caller, hitting a tenant that exists but hasn't reached
the active+credentialed gate yet -- must be refused, not served) was
still an explicitly-skipped stub in
api/queryapi/tenant_isolation_gap_test.go.

Investigating it found the two storage engines needed genuinely
different treatment:

- ClickHouse (enterprise/internal/chrunner) already had this property
  structurally, for free: Registry is built once at startup from
  rbacstore.ListProvisionedDataSources, which already filters to
  active+credentialed tenants only, so a mid-provisioning tenant is
  simply absent from the connection map. New test
  TestRegistryRefusesMidProvisioningTenant proves this without Docker
  -- an empty DataSource list never dials ClickHouse, so this genuinely
  runs in this environment, unlike every other test in that file.

- Tantivy (search/src/registry.rs's IndexRegistry) was a real, different
  gap, not just an unverified assumption: it opens-or-creates an index
  for any syntactically-valid tenant_id on first request, because it's
  a separate process with no Postgres access and structurally can't
  know which tenants are actually provisioned. A query against a
  mid-provisioning tenant would have silently succeeded with zero
  results from a freshly-created empty index -- "ambient success"
  indistinguishable from "no matching logs," exactly the failure mode
  this item was worried about.

Fixed the Tantivy gap with a new enterprise/internal/searchclient.
TenantChecker interface (backed by a new rbacstore.TenantIsActive,
implemented structurally, no new import edge needed), consulted before
every gRPC call: Client.Search now refuses a non-active tenant before
it ever reaches `search`. Dial's signature gained a required
TenantChecker parameter; enterprise-api's main.go passes its existing
rbacstore.Store (already satisfies the interface). Verified Docker-free
via searchclient's existing real-in-process-gRPC-server test harness
(TestSearchRefusesMidProvisioningTenant, plus
TestSearchPropagatesTenantCheckerError for the fail-closed-on-error
case) -- both genuinely run in this environment, same bar as the rest
of the Tantivy isolation work.

rbacstore.TenantIsActive itself has two new skip-gated live-Postgres
tests (TestTenantIsActive, TestTenantIsActiveNonexistentTenant) --
disclosed as not run against a live database here, same gap as the
rest of this phase's Postgres-backed pieces.

api/queryapi/tenant_isolation_gap_test.go rewritten from a checklist
with one skipped stub to a full accounting of all four now-closed
probes. Docs updated in lockstep: CLAUDE.md, threat-model.md,
phase-4-isolation-design.md (implementation note added after its
original sign-off), phase-4-runbook.md (§9), enterprise/README.md.

docs/phase-4-isolation-design.md

@@ -315,3 +315,25 @@ suite must include, against the live stack:
 - A simulated evaluator tick firing mid-provisioning (tenant row exists,
   grants not yet confirmed) to confirm it's refused, not silently served
   against a partially-provisioned or default-profile connection.
+
+  **Implementation note (Phase 4 task 8, added after this design was
+  signed off):** closed for both storage engines, via
+  `api/queryapi/tenant_isolation_gap_test.go`'s pointers. ClickHouse's
+  refusal turned out to be structural, not something that needed new
+  code: `chrunner.Registry` is built once at startup from
+  `rbacstore.ListProvisionedDataSources`, which already excludes
+  anything short of active+credentialed, so a mid-provisioning tenant is
+  simply absent from the connection map — proven Docker-free
+  (`chrunner_test.go`'s `TestRegistryRefusesMidProvisioningTenant`,
+  since an empty `DataSource` list never dials ClickHouse). Tantivy was
+  a real, different gap: `search/src/registry.rs`'s `IndexRegistry`
+  opens-or-creates an index for *any* syntactically-valid `tenant_id` on
+  first request, because it's a separate process with no Postgres
+  access and structurally cannot know which tenants are provisioned --
+  without a check upstream, a mid-provisioning tenant's query would have
+  silently succeeded with zero results from a freshly-created empty
+  index. Fixed by adding `enterprise/internal/searchclient.
+  TenantChecker` (backed by a new `rbacstore.TenantIsActive`): `Client.
+  Search` now refuses before the gRPC call goes out if the tenant isn't
+  active, verified Docker-free via a real in-process gRPC server
+  (`searchclient_test.go`'s `TestSearchRefusesMidProvisioningTenant`).