[Feature] OrcaRouter provider support for WeSight

## Problem Statement

Local coding agents such as Claude Code, Codex, OpenClaw, and Hermes Agent are powerful, but their setup, model routing, permissions, and runtime metrics usually live in separate terminal worlds. WeSight pulls them into one desktop workspace with a beginner-friendly install and detect flow, visual chat with tool panels and diffs, Feishu IM routing, and an AI Runtime Dashboard that tracks tokens, TTFT, and per-engine throughput. That visibility is the first thing to go missing when people mix several engines.

Because WeSight already makes model providers a first-class setting, from official OpenAI, Anthropic, and Gemini to OpenAI-compatible endpoints for DeepSeek, Qwen, Moonshot, Ollama, OpenRouter, and custom gateways, another well-behaved provider extends that value directly: users can point every supported engine at models that fit their cost and latency needs.

## Proposed Solution

I propose [OrcaRouter](https://www.orcarouter.ai) as an optional, additive provider for WeSight. OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, so it fits the same slot where WeSight already manages OpenAI-compatible endpoints, and it would not replace or alter any existing provider. For users running several coding agents through one workspace, the most relevant capabilities are:

- Many chat, reasoning, image, and video models through one endpoint, so a single key covers a wider range of model choices.
- Automatic model routing and provider failover, complementing WeSight's per-engine model mapping.
- Usage tracking and budgets, so shared keys do not become surprise bills.
- Team access controls for groups sharing one WeSight setup.

The expected integration point is the model-provider layer behind the Settings UI and the engine adapters under `src/main/libs/agentEngine`: adding OrcaRouter would resemble adding another OpenRouter-style entry, a base URL plus an API key that engines following WeSight-managed settings can select. This is a proposal only; no implementation or testing has been done, and nothing requires an architecture change.

OrcaRouter is already integrated in open-source projects such as Dify, promptfoo, goose, and OpenCode, with examples at https://www.orcarouter.ai/built-with.

For transparency, I'm an engineer on the OrcaRouter team. We run an optional partner program where approved open-source projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. Participation is not a prerequisite for adding or using the provider, and I am happy to follow any disclosure or governance requirements this project prefers.

## Alternatives Considered

Users who want broader model coverage today can add OrcaRouter's endpoint as a custom provider themselves. A built-in option would make that discoverable and documented for everyone and let WeSight apply its own labels, routing, and telemetry consistently.

## Additional Context

Maintainers, I would welcome your thoughts on whether an OrcaRouter preset fits the project's direction. With your go-ahead, I am glad to open an implementation PR (provider entry, docs, and tests) that follows your contribution guidelines.

### Checklist

- [x] I have searched for existing feature requests
- [x] This feature would be useful to other users

Start with the model-provider layer behind the Settings UI and the engine adapters under src/main/libs/agentEngine. Compare the proposed entry with the existing OpenRouter-style provider and confirm the maintainer's preferred scope before implementing. Done should include a selectable OrcaRouter provider, documentation, and tests as described in the proposal.

Written by the indexing model from the issue text.