OrcaRouter provider support for ShellSage

ShellSage's tmux integration is what makes it click: because it reads your pane history (or a named pane via `--pid`) and accepts piped input, a line like `journalctl --since "1 hour ago" | ssage explain this error` turns a stack trace into a plain-language diagnosis without leaving the terminal. The `ssage_clear` binding is a thoughtful design choice too — Ctrl-L gains real clear semantics for the assistant while your own scrollback stays intact.

That matters because people who live in a shell want answers where they already are, and model choice is part of that. ShellSage already resolves models through fastllm and accepts a custom `base_url`/`api_key`, so OrcaRouter would slot in as one more optional provider alongside Claude, GPT, and Ollama.

### Proposal

I'd like to propose adding OrcaRouter as an optional provider. It would not replace or change any existing provider — Claude, GPT, Gemini, Ollama, OpenRouter, and the rest would keep working exactly as they do today.

I'm an engineer on the OrcaRouter team, so I'll be upfront about my angle here.

### What this would give ShellSage users

- **One endpoint, many models** — chat, reasoning, image, and video models behind a single OpenAI-compatible API, so `--model` can point at a much wider catalog.
- **Automatic routing and provider failover** — if a provider degrades mid-session, a request routes to a healthy equivalent instead of dropping your question.
- **Prompt caching** — especially relevant here, since `history_lines = -1` ships the whole terminal history on every call; caching makes that repeated context cheaper and faster.
- **Usage tracking and budgets** — visibility into what a long-running shell session actually costs.

### Integration

OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication. Concretely, this fits the abstraction you already have: an `orcarouter`-style prefix resolved by fastllm next to the current vendor prefixes, or simply the existing `base_url` / `api_key` config and CLI options, both of which already flow through to `AsyncChat`. To be clear, I haven't written or tested any code for this — it's a proposal for your consideration.

OrcaRouter is already part of the open-source ecosystem, with integrations such as goose, promptfoo, and models.dev / OpenCode.

One disclosure: we run an optional open-source partner program where approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. Taking part is not a prerequisite for the integration, and I'm glad to follow whatever disclosure or governance rules you'd prefer.

Details: https://www.orcarouter.ai/built-with

Would you be open to this? If so, I'd be happy to prepare an implementation PR once you've had a chance to weigh in.

Start by tracing fastllm provider resolution and the existing base_url/api_key flow into AsyncChat, then compare the current vendor prefixes and CLI model options. Done means an optional OrcaRouter-compatible provider is integrated without changing existing providers, with the provider behavior covered by the project's existing checks.

Written by the indexing model from the issue text.