feat(providers): add OrcaRouter as a named provider

[nissrin2020ali-ux]

Summary

Cebian's promise is "bring your own API key from any model provider" and its feature table lists "OpenAI, Anthropic, Google, and any OpenAI-compatible endpoint via custom providers." That last bucket is where gateway services end up today — but a gateway isn't just an anonymous base URL, it's a provider with its own model namespace and its own routing behavior. OpenRouter already gets first-class treatment in the Settings → "Via API Key" list; this PR gives OrcaRouter the same treatment.

OrcaRouter is an OpenAI-compatible AI gateway built for both models and agents. Like OpenRouter, it exposes a provider/model namespace across many models — but it also combines adaptive routing, automatic failover, zero-markup inference, observability, guardrails, and agent-tool governance behind the same endpoint. Adding orcarouter as a first-class provider means Cebian users can use that stack directly, without treating OrcaRouter as an anonymous custom base URL. It also runs gateway-level, zero-trust security for AI agents on the same endpoint — screening every prompt/response and governing every tool call on a default-deny basis, with no application code changes.

What changed

• lib/providers/registry.ts — added orcarouter to APIKEY_PROVIDERS, so it shows up in Settings → Providers alongside OpenRouter.
• lib/providers/orcarouter.ts (new) — a small catalog of OrcaRouter's native auto-routing models (orcarouter/auto, orcarouter/free, orcarouter/fusion, orcarouter/fusion-flash, orcarouter/fusion-mini), pointing at https://api.orcarouter.ai/v1 with the same Cebian attribution headers the OpenRouter integration sends. Vendor-prefixed models (e.g. deepseek/deepseek-chat) are intentionally left out — Cebian already ships dedicated providers for those vendors, and OrcaRouter exposes hundreds of them with no per-model metadata to curate against.
• lib/providers/resolve-model.ts — resolves orcarouter from that local catalog (it lives outside pi-ai's generated model catalog), mirroring the existing openrouter special case.
• lib/providers/usable-models.ts — the model selector lists OrcaRouter models once an API key is stored.
• components/settings/provider/ProviderApiKeyItem.tsx / ProviderSummary.tsx / components/chat/ModelSelector.tsx — the API-key connectivity test, provider summary, and model picker all read from the OrcaRouter catalog.

Why a small static catalog instead of a dynamic fetch

OrcaRouter's /v1/models returns 200+ entries with no cost/context metadata, and its unique value is the orcarouter/* routing models — those are what this catalog ships. Users can still add any specific vendor/model as a custom OpenAI-compatible provider if they want a pinned upstream.

Testing

• pnpm run check passes locally (typecheck + i18n lint + 674 tests, including new unit tests for the catalog, resolveModel, and listUsableModelGroups).
• Live-tested the exact runtime path against the real endpoint: resolveModel({ provider: 'orcarouter', modelId: 'orcarouter/auto' }) → complete() from @earendil-works/pi-ai/compat (the same call ProviderApiKeyItem uses for its connectivity check) returned an "ok" completion from OrcaRouter's live API with maxTokens: 5. Skipped automatically when no API key is present.
• Verified orcarouter/auto passes Cebian's connectivity heuristic (maxTokens: 5, expects "ok"), and that OrcaRouter accepts max_tokens and the HTTP-Referer/X-Title attribution headers.

Related Issues

Closes #64

Checklist

• pnpm run check passes locally
• I have read and agree to the Cebian CLA

---

I'm an engineer on the OrcaRouter team.

Discord: discord.gg/YEubt8enRA · X: https://x.com/OrcaRouter

[github-actions]

👋 感谢你的贡献！不过这个 PR 暂时被系统自动关闭了。

本项目要求：每个 PR 必须关联一个经过维护者批准的 issue（带 ready-to-implement 标签），这样才能确保在动手写代码之前，实现方向已经达成共识。

怎样让这个 PR 被接受：

1. 先去对应的 issue 里讨论你的方案；
2. 等维护者在该 issue 下回复 /ready，给 issue 打上 ready-to-implement 标签；
3. 确保你的 PR 描述里写了 Closes #；
4. 重新打开这个 PR，系统会再次检查，通过后就会自动放行（合并）。

如果你觉得这是误判，欢迎在评论区告诉我们。

---

👋 Thanks for contributing! This PR was auto-closed for now.

This project requires every PR to reference an issue that has been approved by the maintainer (carrying the ready-to-implement label), so that the approach is agreed upon before implementation.

How to get it accepted:

1. Discuss your approach in the related issue first;
2. Wait for the maintainer to reply /ready and apply the ready-to-implement label;
3. Make sure your PR description includes Closes #<issue number>;
4. Reopen this PR — the gate will re-check and let it through.

If you believe this was a mistake, feel free to comment.