feat: define agentic config proposal and patch contract

Summary

Define the proposal format for offline agentic config tuning so generated changes are reviewable, diffable, and evaluable before activation.

Parent roadmap: #2287 Parent issue: #2340 Depends on: #2326, #2333 Related code: src/semantic-router/pkg/config, dashboard/backend/evaluation, dashboard/backend/handlers/config.go, src/semantic-router/pkg/routerreplay, src/semantic-router/pkg/dsl

Motivation

Offline tuning should not mutate live config directly. It needs an intermediate proposal artifact that can describe changes to signals, thresholds, projections, decisions, recipes, model selection weights, or docs, along with evidence and expected impact.

Scope

Define a proposal contract containing:

• source artifacts and dataset/replay references;
• structured config patch or candidate snapshot;
• rationale and affected routing surfaces;
• expected metric changes and risk notes;
• validation and rollback metadata;
• compatibility with config diff/activate APIs.

Non-goals

• Do not accept LLM-authored rules without eval evidence.
• Do not create a second config schema for proposals.
• Do not activate proposals from the request path.

Acceptance criteria

• Proposal artifacts can be validated, diffed, and evaluated against decision-level harnesses.
• Human reviewers can understand what changed and why.
• Rejected proposals leave no runtime side effects.