feat(providers): add OrcaRouter as a named provider

[JinhaoSong322]

Summary

Adds OrcaRouter as a named cloud-gateway provider in the shipped model registry, mirroring the existing data-driven provider flow.

• models.json: new orcarouter provider entry — api: "openai-completions", baseUrl: "https://api.orcarouter.ai/v1", apiKey: "ORCAROUTER_API_KEY" — with six models covering the gateway's auto-routing alias (orcarouter/auto), fast/cheap (orcarouter/fusion), free tier (orcarouter/free), and vendor-qualified frontier models (DeepSeek V4 Pro, Qwen3.7 Max, Gemini 3.5 Flash via OrcaRouter).
• .pi/extensions/llama-cpp-provider/config.ts: register orcarouter in the per-provider env-override map so ORCAROUTER_BASE_URL overrides the default endpoint.
• Tests: ORCAROUTER_BASE_URL override case + shipped-registry assertions (base URL, API-key env, orcarouter/auto presence).
• README.md: "OrcaRouter (cloud gateway)" section with setup, model list, and env vars.
• CHANGELOG.md: Unreleased entry.

OrcaRouter is an OpenAI-compatible gateway that fronts both open-weight and frontier models behind a single endpoint. 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.

Verification

• vitest run: 614 passed; the 8 failures are pre-existing environment issues (launcher needs the bundled pi version on --version, browser-extract-retention hits live Wikipedia, glob hits a memory-bound walk) — confirmed identical on a clean main tree.
• tsc --noEmit: clean.
• Live test against https://api.orcarouter.ai/v1 through the exact production path (loadProviders → applyEnvOverrides → orcarouter provider): HTTP 200, auto-routed to deepseek-v4-pro, reply ORCA-OK.

Disclosure: I'm an engineer on the OrcaRouter team.

[itayinbarr]

Thanks for the clean patch, and for the up-front disclosure. The code is not the problem here: it follows the data-driven provider pattern exactly, the env-override wiring is in the right place, and you tested it live. I am still going to decline it.

The shipped models.json is not a directory of everything little-coder can talk to. It is the set of backends I can stand behind, and in practice that means local llama.cpp and Ollama plus the handful of gateways I actually run and re-verify when a release goes out. Carrying orcarouter would mean shipping model IDs, pricing assumptions, and an endpoint I have no way to keep honest, and once one commercial gateway is in the registry by way of its own vendor, I have no principled line for the next one.

The good news is that you do not need me for this. The registry is overridable per provider, so anyone who wants OrcaRouter gets it without a fork:

• Put the orcarouter provider block from this PR in your own models.json at ~/.config/little-coder/models.json (or $XDG_CONFIG_HOME/little-coder/models.json, or anywhere you like with LITTLE_CODER_MODELS_FILE pointing at it). Resolution order is in llama-cpp-provider/index.ts.
• ORCAROUTER_API_KEY works through the standard apiKey field with no code change. The one piece that genuinely needs the registration in your config.ts diff is the ORCAROUTER_BASE_URL override, and users can just set baseUrl in their own file instead.

If you publish that file somewhere, I am happy to link it from the README's provider section as a third-party config, which gets your users the same result and keeps ownership where it belongs.