fix(search): resolve server-tool generation ids

[ayush-or]

Why search parquet IDs pointed at zero-usage rows

Server-tool search returns a client-visible orchestration generation while its recursive child generations carry model usage. The benchmark collector persisted that root ID, so downstream analysis treated a zero-usage wrapper as the evaluated model call.

TL;DR

Mark server-tool search responses for relation expansion and extend the existing generation resolver to replace wrapper/cache IDs with their underlying leaf generation IDs. Plugin search and non-search callers keep their existing IDs, and failed resolution falls back to the original ID.

What changed

• Track whether a collected Responses generation may have child generations.
• Mark the shared server-tool search path; plugin search remains direct.
• Resolve related generation trees recursively with cycle/depth protection.
• Preserve existing cache-source usage replay and auxiliary-call behavior.
• Keep the existing generation_ids result contract and parquet schema.

Sequencing

The OpenRouter monorepo PR will add the authenticated include_related=true generation projection and sync this subtree commit. Without that endpoint projection, resolution safely retains the root ID.

Validation

• 253 focused and search benchmark tests passed in the monorepo checkout.
• bun run check, bun run typecheck, and bun run build passed.
• bun run verify passed in the monorepo checkout.

Reviewer focus

• Cache-hit source traversal must continue replaying usage exactly once.
• Live server-tool roots should expand IDs without replaying already-reported usage.
• Plugin search and auxiliary judge calls must not opt into child expansion.