feat(search): add optional TypeSafe Jev reranking

What problem does this solve?

GBrain's provider registry and reranking gateway do not support TypeSafe's native System One API. Users with a TypeSafe key cannot select Jev for retrieval reranking through the existing search configuration.

What does the solution look like?

Add an optional TypeSafe recipe and native Jev adapter through the existing gateway, as implemented for review in #5178.

• Select typesafe:jev-1.13.0 or typesafe:jev-latest through search.reranker.model and the existing enabled setting.
• Load TYPESAFE_API_KEY through the existing home .env or process environment; key presence alone does not change provider selection.
• Send one independent Score question per candidate with shared query state, validate complete bounded scores, normalize relevance and preserve global indices and stable ties.
• Preflight native context/payload estimates, pack candidates and run bounded batches under one deadline using existing authorization and cost accounting.
• Preserve all production Voyage code, provider defaults, search orchestration, schema and downstream score thresholds. Existing skip/failure reporting preserves original search order.
• Document setup, integration behavior, reproducible evaluation controls and actual measurements.

Alternatives considered

Keeping Voyage alone does not provide a TypeSafe option. Sending the standard rerank JSON shape to Jev would miss its native typed question API. A separate configuration plane or automatic key-based replacement would add unnecessary architecture and change existing installations.

Evaluation evidence

Completed six-profile evidence and protocol and 100-document extension with individual request data retain frozen-input generators, raw receipts, source manifests and all 85 performance HTTP records. Each provider/profile has one execution on the same synthetic candidates.

Long-document profile	Active ms Voyage / Jev	Total nominal USD Voyage / Jev
50 × 6,000 characters	7438.43 / 1582.17	0.002502400 / 0.002515716
100 × 6,000 characters	14401.02 / 1899.14	0.005004900 / 0.005031516

Jev had 78.7% and 86.81% lower active elapsed time in these observations, at approximately 0.53% higher nominal cost. Voyage was faster and cheaper on the two smaller profiles and cheaper on every profile. Both returned all candidates and ranked the expected policy first.

Voyage rerank-3 selection, splitting, rolling 3 RPM / 10K TPM admission, quota-constrained concurrency and truncation:false are evaluation-only controls for a free account, not production Voyage changes. Active time includes client/batching/network effects; wall additionally includes quota gaps. These results do not establish an untouched large-pool single-request baseline, paid-account capacity, minimum request counts, held-out quality equivalence, latency distributions or a universal winner. Costs sum native reported input across all requests at list prices, excluding free credits.

Acceptance criteria

• Explicit existing configuration selects Jev without changing other installations.
• Production Voyage recipe and standard rerank request/response/budget/failure behavior remain intact.
• Native score validation, context packing, stable mapping, cancellation/deadline, invocation policy and usage/cost handling are covered.
• Hybrid-search checks cover score stamping, autocut/CRAG consumption, failure auditing/pass-through and relational pinning.
• Setup and reproducible benchmark evidence are documented with their limitations. Independent quality/score-threshold calibration remains separate evaluation work.