[feat] OrcaRouter provider support for TeamAI

TeamAI manages a team's AI experience from a shared git repo: admins push skills, rules, hooks, MCP servers, and env vars, and every member's Claude Code, Cursor, or CodeBuddy session pulls them on start, so the whole team executes the same way. Its friction-based sharing model, which suggests documenting a learning after a session that fought a problem, turns daily agent struggles into reusable team knowledge.

That governance instinct extends to models: TeamAI can push an apply_model_config task that writes a provider/model entry (base_url, api_key) into the right agent config, like ~/.codebuddy/models.json or a Claude teamai-models.json profile, so an admin decides which endpoints a team may use. I'd propose OrcaRouter as another optional OpenAI-compatible provider in that flow, giving members more model choice under the same central control.

Problem

Teams using TeamAI want members to reach more model endpoints without each person managing their own provider accounts, and without the team running its own gateway. A team that wants several chat or reasoning models behind one managed endpoint has no ready-made option to ship through TeamAI's model-config delivery.

Proposed Solution

Add OrcaRouter as an optional, documented provider for TeamAI's model delivery. OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, so from TeamAI's side it is just another provider / model_id / base_url / api_key entry, the same shape apply_model_config already writes into ~/.codebuddy/models.json, ~/.workbuddy/models.json, or a Claude teamai-models.json profile via the ANTHROPIC_CUSTOM_MODEL_OPTION gateway. Existing providers and entries stay untouched; this is additive. Three OrcaRouter capabilities fit TeamAI's admin-and-member model well:

• One endpoint, many models: chat and reasoning models from several providers behind a single OpenAI-compatible base URL, so one shipped entry covers a whole model menu.
• Automatic model routing and provider failover: a member's session stays productive when an upstream provider degrades.
• Usage tracking and budgets: account-level visibility and limits that complement TeamAI's own teamai digest and dashboard.

Alternatives Considered

Individually managed provider accounts weaken the team-level governance TeamAI provides. A self-hosted proxy works but leaves failover, caching, and budget tooling for the team to build and maintain.

Additional Context

OrcaRouter already integrates with OSS projects including RAGFlow, Dify, goose, and promptfoo.

Full disclosure: I'm an engineer on the OrcaRouter team. OrcaRouter has an optional open-source partner program: approved OSS projects can receive a 5% revenue share of usage attributed to their integration. Participation is not a prerequisite for integrating, and I'll follow any governance or disclosure rules TeamAI prefers. See https://www.orcarouter.ai/built-with.

I'd welcome maintainers' feedback on fit, and I'm glad to submit an implementation PR if approved.