[feature]: OrcaRouter provider support for ByteChef

### Tell us about the problem you're trying to solve

ByteChef unifies AI agent orchestration and workflow automation in one platform, so an agent can be a step in a workflow and a workflow can become an agent tool, all under one audit log. Because an agent's quality depends on the models behind it, the per-environment **AI Providers** catalog and router-style LLM components such as OpenRouter show how deliberately ByteChef manages model credentials and model choice for teams that deploy across Development, Staging, and Production. That is why ByteChef users would benefit from one more well-integrated option.

**OrcaRouter** is proposed here as an optional, purely additive provider. It would not replace or alter any existing provider or connection, and it would follow the credential model ByteChef users already know: one API key per environment instead of one per model vendor.

### Describe the solution you'd like

[OrcaRouter](https://www.orcarouter.ai) is a model gateway that exposes an **OpenAI-compatible API** and uses **standard API-key authentication**, serving many chat, reasoning, image, and video models through one endpoint. For ByteChef agents and workflows, the most relevant capabilities are automatic **model routing and provider failover** (a step keeps running if an upstream provider is down), **prompt caching** for repeated agent and tool calls, and **usage tracking with budgets** for a single view of model spend.

The natural integration point mirrors what already exists: provider components under `server/libs/modules/components/ai/llm/` (for example the OpenRouter module) reuse a shared `RouterConnection.connectionDefinition(baseUrl)` that wires a base URI plus `BEARER_TOKEN` API-key authorization. OrcaRouter's OpenAI-compatible surface should fit that pattern as a new component and/or AI Providers catalog entry. This is a proposal only: no code has been written or tested, and I would rely on ByteChef maintainers to confirm where a new provider belongs.

OrcaRouter already cooperates with open-source platforms such as RAGFlow, Dify, goose, and promptfoo, following an established pattern of gateway providers working with OSS tools.

### Describe the alternative you've considered or used

Teams that want a multi-model gateway today configure OpenRouter manually or wait for the in-development EE AI Gateway. OrcaRouter would be an additional, optional choice that brings its own caching, budgets, and failover behavior into ByteChef's existing provider model.

### Additional context

Transparency disclosure: OrcaRouter runs an **optional open-source partner program** in which approved OSS projects can receive a **5% revenue share** from OrcaRouter usage attributed to their integration. Participation is **not** a prerequisite for this integration, and I am happy to follow ByteChef's governance and disclosure expectations either way. Other open-source integrations are listed at https://www.orcarouter.ai/built-with.

I'm an engineer on the OrcaRouter team. I would welcome maintainers' input on whether a provider component fits ByteChef's architecture, and with your go-ahead I would be glad to contribute the implementation as a PR following the component contribution guide.

Start with the provider components under server/libs/modules/components/ai/llm/ and compare the existing OpenRouter module with the shared RouterConnection.connectionDefinition(baseUrl). Read the component contribution guide and confirm with maintainers whether this belongs as a new component or an AI Providers catalog entry. Done means an optional OrcaRouter integration using its OpenAI-compatible endpoint and API-key authentication, with tests added for the integration.

Written by the indexing model from the issue text.