OrcaRouter provider support for dirge

dirge is a minimal, fast coding agent written in Rust, and its role-based multi-provider routing stands out: the main loop, review, escalation, summarization, and subagent roles can each run on a different model in one session, mixing Cerebras, DeepSeek, GLM, Anthropic, OpenAI, Ollama, and any OpenAI-compatible endpoint. That design keeps cheap models on the rails while escalating to a stronger one on repeated failure.

Because dirge resolves providers through `provider_type` and `base_url`, an OpenAI-compatible endpoint already fits with little more than a base URL — that's how a local Ollama and GitHub Copilot are wired in today. For a developer who already runs dirge on a laptop, adding another OpenAI-compatible provider means more options for those role slots, with no change to anything they already use.

### What I'm proposing

I'd like to propose [OrcaRouter](https://www.orcarouter.ai) as an optional provider for dirge, alongside OpenRouter, OpenAI, Anthropic, Gemini, DeepSeek, GLM, Cerebras, OpenCode, and Ollama — replacing none of them. I'm an engineer on the OrcaRouter team, and I'm writing to ask whether maintainers would accept this before any code is written.

### Integration shape

OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, so in dirge's terms it could be declared as a provider alias with `provider_type: "openai"` and `base_url: https://api.orcarouter.ai/v1` — the same path Ollama and GitHub Copilot already take, with a dedicated `provider_type` as a possible later convenience. I'm deliberately not claiming any implementation exists or has been tested; this is a proposal for discussion.

### Why dirge users might care

- **One endpoint, a wide catalog** — 200+ chat, reasoning, image, and video models behind a single base URL and key, which fits dirge's role routing: keep the main loop cheap and point escalation or critic roles at frontier models through the same alias.
- **Automatic routing and provider failover** — prompts are graded and routed, with fallback before a response starts, complementing dirge's escalation and circuit-breaker logic.
- **Prompt caching billed at the provider's cache rate**, in the same spirit as dirge's own `prompt_cache` tuning for long sessions.
- **Usage tracking and budgets** — per-request logs with model, latency, and cost, plus spend caps, for cost-sensitive setups.

OrcaRouter is already used by open-source tools like OpenCode, Dify, and models.dev, and we'd follow dirge's conventions for documenting a provider.

### Disclosure

OrcaRouter runs an optional open-source partner program: approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration (see https://www.orcarouter.ai/built-with). Participation is not a prerequisite — if you'd prefer no such arrangement, that changes nothing — and I'm happy to follow whatever disclosure or governance rules dirge prefers.

If this sounds useful, I'd welcome maintainers' input on whether OrcaRouter should be a built-in provider type or a documented OpenAI-compatible alias, and with your go-ahead I'd be glad to prepare an implementation PR.

No source file or test is named. Start by tracing dirge's existing Ollama and GitHub Copilot OpenAI-compatible provider configuration and the provider_type/base_url resolution path. Done means deciding between an alias and dedicated provider approach, then verifying OrcaRouter authentication and compatibility without affecting existing providers.

Written by the indexing model from the issue text.