Phase 7 — Add OpenRouter provider integration

[maximalang]

Phase 7 scope

Add OpenRouter as a first-class LLM provider through the existing canonical Provider → Account → Canonical Model → Model Route → route resolver → LiteLLM projection → LiteLLM gateway → durable execution architecture.

Phase 6 prerequisite

Corrective World Phase 6 PR #61 merged successfully.

• Phase 6 merge SHA: 57f98f7c2112f81f338c158dcd5481e04f184384
• Phase 7 base: 57f98f7c2112f81f338c158dcd5481e04f184384
• branch: codex/phase-6-openrouter-provider (historical name predates corrective World Phase 6)

Constraints

• reuse existing OPENROUTER ProviderKind
• no parallel OpenRouter gateway, dispatcher, runtime, or secret store
• API keys stay server-side and encrypted via the existing provider credential path
• fixed OpenRouter API origin: https://openrouter.ai/api/v1
• canonical remoteModelId preserves the upstream provider/model slug
• LiteLLM provider model is derived only at the resolver/projection boundary as openrouter/<provider>/<model>
• repository LiteLLM verifier is pinned to ghcr.io/berriai/litellm@sha256:154e23bb5f31b1f10e16392a8ef299bd2cde08de3a64a6849002cfcc25ce3c63 (LiteLLM v1.96.2)
• standard CI must not require a live OpenRouter key
• no World redesign
• no deployment
• keep this PR Draft; do not merge

Current status

The pre-existing implementation was rebased cleanly onto merged Phase 6 with no overlapping World files. Phase 7 acceptance hardening, targeted Hub evidence, and full CI verification remain in progress.