Phase 2: unified query language spanning ClickHouse and Tantivy

Replaces the separate SQL-only /query and text-only /search endpoints
with one pipe-syntax query language (plus raw SQL escape hatch) that
compiles to a single IR and execution plan across both backends, so a
query like `message:"connection refused" | stats count by host` runs
as one request instead of two disjoint tools.

- api/internal/querylang: lexer -> ast -> parser -> ir -> planner ->
  executor, each layer independently tested.
- Execution generalizes Phase 1's proven Tantivy-prefilter pattern
  into a 4-way routing table (pure ClickHouse / text-only / text +
  aggregation / raw SQL passthrough).
- Unified web query page and `sentryctl query`, both hitting the same
  POST /query endpoint.
- Benchmarked against a real 1,022,000-row dataset
  (hack/benchmark-fixture); caught and fixed a real bug where the
  Tantivy prefilter cap (10,000) produced an IN-clause exceeding
  ClickHouse's default max_query_size -- lowered to 5,000, documented
  in docs/query-language-design.md and docs/phase-2-runbook.md.
- docs/query-language-reference.md: customer-facing syntax reference.

api/internal/searchclient/client.go

@@ -1,6 +1,8 @@
 // Package searchclient adapts the generated gRPC SearchServiceClient to
-// the narrow queryapi.searchClient interface, so queryapi doesn't need to
-// know anything about gRPC/protobuf directly.
+// the narrow querylang/executor.SearchClient interface (Search(ctx,
+// query string, limit uint32) ([]string, error), satisfied structurally,
+// no adapter type needed), so the query executor doesn't need to know
+// anything about gRPC/protobuf directly.
 package searchclient
 
 import (