OrcaRouter provider support for ComfyUI Partner Nodes

The Partner Nodes section solves a real problem: it explains how ComfyUI calls closed-source models through API requests, so users reach external models "without complex API key setup" while ComfyUI core stays open source and local. The OpenRouter LLM page is the clearest example, describing one API that exposes many providers so a workflow can switch models without changing its integration, with inputs that appear per model for vision, video, and reasoning effort.

The repo's tooling makes the same bet. `.env.local.example` documents its translation and review backends as an "OpenAI-compatible endpoint" and names OpenRouter, DeepSeek, and DashScope Qwen-MT as interchangeable. An OrcaRouter provider would add one more opt-in option beside the providers these docs already cover.

## Proposal: OrcaRouter as an optional Partner Node provider

I'm an engineer on the OrcaRouter team. [OrcaRouter](https://www.orcarouter.ai) is an AI gateway that exposes chat, reasoning, image, and video models from many providers through one API. This is a proposal for an additional opt-in provider. It would not replace or change any existing Partner Node, the Comfy Cloud nodes, or the documented `--disable-api-nodes` behavior.

Why it may fit ComfyUI users:

- **One endpoint across modalities.** Chat, reasoning, image, and video models sit behind a single base URL, which matches the image, video, audio, and LLM spread of the current Partner Nodes.
- **Automatic model routing and provider failover.** Requests are matched to a suitable model, and retries land on healthy fallback capacity, so a long graph is less likely to stall on one provider's bad day.
- **Usage tracking with budgets and team access controls.** Per-request logs with model, latency, and cost, plus spend caps and seats, echo the "Controlled costs" advantage the Partner Nodes overview already promises.
- **Prompt caching.** Cached input tokens are billed at the provider's cache rate, which helps repeated system prompts and automated pipelines such as the docs translation and review runs.

OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication. Based on the provider abstraction already in this repo, an OrcaRouter node would be a sibling of the existing LLM provider node, and an OrcaRouter base URL would be a drop-in option for `TRANSLATE_API_BASE_URL` and `REVIEW_API_BASE_URL`. I have not written or tested any code for this. It is a proposal only, and I would follow whichever implementation path maintainers prefer.

OrcaRouter is already in use across open-source tooling, including Dify, RAGFlow, promptfoo, and models.dev / OpenCode.

In the interest of transparency: OrcaRouter runs an optional open-source partner program. Approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. Taking part is not a prerequisite for an integration, and I am glad to follow this project's disclosure and governance requirements.

More detail: https://www.orcarouter.ai/built-with

Would you be open to an OrcaRouter provider here? I am happy to answer questions about routing, pricing, or data handling first, and to open an implementation PR if that would be welcome.

Start by locating the Partner Nodes section, the OpenRouter LLM page, and `.env.local.example`, then review how existing LLM providers and `TRANSLATE_API_BASE_URL` and `REVIEW_API_BASE_URL` are documented. A maintainer decision is needed before implementation; done would mean an agreed OrcaRouter provider scope, location, configuration, and documentation, with any relevant examples or tests updated.

Written by the indexing model from the issue text.