feat: add offline agentic config tuning with human and CI approval

Summary

Add an offline, proposal-based config/recipe tuning loop. It may generate candidate routing changes from Router Replay/evaluation data, but evaluation, validation, CI/human approval, activation, provenance, and rollback remain mandatory.

Parent roadmap: #2287
Depends on: #2326, #2333
Related: #1512, #2238, #2241, #2330, #2331, #2393, #2558, #2559

Child issues

• #2366 — structured proposal and patch contract
• #2367 — approval, activation, and rollback flow

Audited upstream baseline (2026-07-15)

• The accepted Router Learning design separates bounded online routing_sampling adaptation from broader offline recipe learning. The online path exists; the end-to-end offline proposal/evaluation/approval loop is the work tracked here and in #2366/#2367/#2393.
• Config parsing/validation, decision DSL, Router Replay, evaluation, dashboard/config APIs, and versioned config projections are existing seams to compose; they do not yet constitute the completed offline loop.
• #2393 tracks the preference-driven recipe objective contract.
• Current main does not authorize hidden request-time mutation of recipe/taxonomy/signal/policy structure.

Scope

1. Build a reproducible, privacy-reviewed training/evaluation snapshot from replay/eval/history artifacts.
2. Define the objective and constraints through #2393; quality/safety/protection/SLO gates precede cost or efficiency gains.
3. Propose a structured patch to supported config surfaces (#2366).
4. Validate schema, unknown fields, references, ownership, and migration.
5. Run decision-level evaluation, fixed baselines, protection/safety/security benches, and affected FleetSim/E2E tests.
6. Produce provenance: data/config/code versions, generator identity, prompt/model when applicable, metrics, uncertainty, and diff.
7. Require CI and/or human approval before activation (#2367).
8. Activate through the supported versioned config path with canary, health checks, and rollback.
9. Keep Router Learning online adaptation narrow; offline proposals cannot smuggle in an unreviewed hot-path learner.

Non-goals

• No hidden request-time config mutation.
• No bypass of validation, diff, approval, activation, or rollback.
• No acceptance of LLM-generated rules without reproducible evidence.
• No automatic pool/control-plane mutation; those actors have separate contracts.
• No replacement of #1512 without explicit coordination.

Acceptance criteria

• Propose, validate, evaluate, diff, approve, activate, observe, and roll back are distinct states.
• Candidate and baseline are reproducible from versioned artifacts.
• Objective/constraint semantics are explicit and compatible with #2393.
• Unknown/unsupported config surfaces fail closed.
• Evaluation includes leakage checks, uncertainty, safety/protection gates, and simple baselines.
• Approval identity and activation/rollback events are auditable.
• A failed or stale candidate cannot activate.
• Existing Router Learning protection and public configuration contract remain intact.

WRP governance relationship

• #2558 defines WRP policy semantics and router/downstream ownership.
• #2366/#2367 define proposal, approval, activation, and rollback.
• #2559 may coordinate guarded recommendations but cannot bypass either actor's gates.
• Pool/LB changes are proposed and actuated through their own reviewed control-plane contract.