OrcaRouter provider support for Frappe Studio

Frappe Studio collapses what is normally a hand-written pile of DocTypes, Vue pages and wiring into one visual surface: drag a frappe-ui layout, bind a Frappe data source with minimal configuration, then drop into a page script mirroring Vue `` with real reactive state and handlers. For developers working inside a bench, the path from prototype to the exported, `bench build-studio-app` production build stays on machinery they already run.

The AI assistant is why I'm writing. It is already provider-shaped: `studio/ai/llm.py` calls itself the only place that knows provider quirks, models live in `ModelRegistry.AVAILABLE` as OpenRouter-prefixed IDs, and one key in Studio Settings feeds them all. Another OpenAI-compatible endpoint there is additive, and would let a bench operator point the assistant at routing and billing they already have.

I'd like to propose [OrcaRouter](https://www.orcarouter.ai) as an optional provider for the AI assistant. To be clear up front: this would not replace, remove or change any existing provider — it is one more entry, and OpenRouter stays exactly as it is today.

A few things that seem genuinely relevant to Studio's users:

- **One endpoint, many models.** Chat, reasoning, and image-capable models behind a single OpenAI-compatible API, which maps onto `ModelRegistry.AVAILABLE` and its `vision_capable` flag — the chat panel already uses that flag to decide whether a screenshot can be attached.
- **Automatic routing and provider failover.** Studio already treats an unavailable model as normal (`get_fallbacks()` drops to the cheap `SIMPLE` model). Upstream failover would let that safety net hold across providers, not just across models on one.
- **Usage tracking and budgets.** The agent loop already requests `stream_options={"include_usage": True}` and tallies tokens per turn, so per-key spend and caps have somewhere natural to surface.

OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, so the expected integration point is the existing `llm.py` adapter plus the `ai_api_key` field on Studio Settings — no new abstraction required. I have not written or tested any code for this; it is a proposal, not a claim that the work is done.

OrcaRouter is already used in open-source projects including RAGFlow, Dify, goose, and promptfoo.

One transparent note: 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. Participating is entirely optional and not a precondition for the integration — I'm happy to follow whatever disclosure or governance rules the project has, and glad to skip it if that's your preference.

Details are at https://www.orcarouter.ai/built-with. I'm an engineer on the OrcaRouter team. Would the maintainers be open to this as a provider option? If it fits your direction, I'm glad to open the implementation PR myself.

<!-- orcarouter-operation:task:435:create_issue -->

The proposed integration point is studio/ai/llm.py, with model entries in ModelRegistry.AVAILABLE and the ai_api_key field in Studio Settings. Read the existing provider handling first; done means OrcaRouter is an optional OpenAI-compatible provider without changing OpenRouter, while preserving model fallback, vision selection, and usage tracking.

Written by the indexing model from the issue text.