feature: add BestOfNLooper with outcome reranking

Summary

Add a production BestOfNLooper that generates a bounded candidate set and returns one existing candidate selected by a configurable outcome aggregation/verifier policy.

Parent research tracker: #2337 Hardening parent: #2336

Blocked by: #1456, #2855, #2856, #2857, #2858, #2861

Why this is a distinct algorithm

• Ratings is an arena/fan-out API that returns multiple choices and performs no internal selection. Adding selection there would silently change its response contract.
• Fusion asks a judge to synthesize a new answer and normally pays panel plus judge stages.
• ReMoM performs multi-round synthesis rather than selecting one complete trajectory.
• Best-of-N returns one candidate unchanged except for existing output-contract normalization, with a simpler and measurable generation-versus-selection cost split.

Research context

• ICML 2025 Sample, Scrutinize and Scale shows sampling plus cross-candidate verification can continue scaling, while out-of-box self-verification is weak.
• ICML 2025 JETTS finds LLM judges competitive for outcome reranking but weaker than process reward models for step-level beam search.
• NeurIPS 2025 Does Thinking More Help? finds parallel reasoning paths can outperform extending one chain under a fixed token budget.
• NeurIPS 2025 Provable Scaling Laws for the Test-Time Compute of Large Language Models motivates black-box knockout/league pairwise selectors.

Proposed design

1. Build candidate call specs from one or more modelRefs, with explicit samples per model, temperature/seed policy, and hard budget reservation.
2. Execute candidates through #2856's shared panel executor.
3. Normalize task answers for comparison without discarding the full candidate text.
4. Aggregate using one configured mode:
   • majority/self-consistency;
   • confidence-weighted majority;
   • pluggable outcome verifier from #2857;
   • pairwise knockout or league comparison.
5. Return the selected original candidate and preserve its model/tool/output-contract semantics where supported.
6. Emit complete attempt, verifier, selection, usage, latency, and stop traces through #2855.

Initial config surface

The exact schema should be finalized with config maintainers, but it needs bounded equivalents of:

• samples / samples_per_model;
• max_concurrent, timeout, minimum successful candidates, and on_error;
• aggregation mode and verifier reference;
• answer extraction/normalization contract;
• deterministic fallback and tie policy;
• request-wide compute budget inherited from #1456/#2861.

Non-goals

• Do not implement token/step-level beam search or MCTS in the Go router.
• Do not synthesize a new answer; that remains Fusion/ReMoM behavior.
• Do not enable arbitrary tool trajectories for independent candidates in the MVP.
• Do not ship enabled-by-default without matched-budget evidence from #2858.

Acceptance criteria

• A decision can select algorithm.type: best_of_n through canonical config, validation, docs, CLI, and ExtProc dispatch.
• Generation is bounded by hard calls, tokens, cost, concurrency, and wall time.
• Majority and one verifier-backed selector are implemented with deterministic tie/failure behavior.
• The selected candidate, all attempts, verifier work, usage, latency, and stop reason are replayable.
• Same-model repeated sampling and heterogeneous model pools are both supported and reported distinctly.
• Output contracts remain valid after selecting a candidate.
• E2E covers success, tie, verifier failure, partial panel, budget exhaustion, and streaming behavior.
• A fixed-budget benchmark compares direct, majority, verifier selection, Fusion, and ReMoM before production recommendation.