guardrails: provider admission policy

[terisuke]

Parent epic: #1

Source brief:

• docs/ai-guardrails/issues/005-provider-admission-policy.md

Problem

The internal distribution needs a stable provider strategy that does not tie product decisions to one transient model name.

Deliverables

• lane policy for zai, openai, and openrouter
• provider allowlist and denylist defaults
• evaluation checklist for OpenRouter-backed candidates
• confidential-repo restrictions for preview, free, or data-collecting models

Acceptance

• provider defaults are expressed in config, not only in prose
• evaluation lane is separate from standard defaults
• policy references official routing and data controls, not assumptions

Notes

• Follow the thin-distribution approach from docs/ai-guardrails/adr/001-thin-distribution-over-deep-fork.md
• Preserve the philosophy imported from claude-code-skills epic feat(guardrails): Wave 8 — review fixes + remaining hooks + multi-model delegation #130: mechanism-first guardrails, fast feedback, pointer-based instructions, and runtime verifiability
• Prefer OpenCode-native config/profile/plugin/command/CI surfaces over core patches

Dependencies

• epic: internal AI guardrails thin distribution for Cor-Incorporated #1
• docs/ai-guardrails/adr/002-provider-admission-lanes.md

[terisuke]

This issue is in the now-required set for the MVP floor tracked in #16. It should establish declarative provider lanes for confidential-code use before broader post-MVP hardening work.

[terisuke]

Starting issue #6 on codex/issue-6-provider-policy.

Planned scope for this PR:

• codify provider admission lanes in docs and add the missing ADR for provider lanes
• express admitted providers and model allowlists in the packaged profile and managed config
• add a dedicated provider-eval lane for OpenRouter-backed evaluation instead of widening the default confidential-code lane
• enforce the lane at runtime in the guardrail plugin via chat.params
• add scenario coverage that proves standard lane, evaluation lane, and blocked provider misuse actually fire

Out of scope for this PR:

• broader replay harness work from guardrails: scenario and replay harness #7
• later CI/release authority from guardrails: authoritative CI and release gates after MVP #14