feat: OrcaRouter provider support for PowerContext

Feature description

Work rarely ends with whoever starts it — that is the problem PowerContext is built around. When a task moves between humans and agents, the reasoning and current state often stay behind in the original conversation. PowerContext keeps that context with the work as Memory and Handoff items, so a new person or agent can pick up from the current state without replaying the full history.

RFC 0016 reflects a choice worth building on: PowerContext keeps Memory services framework-neutral and delegates model calls to Pydantic AI at the provider boundary, letting Generation, Embedding, and the optional reranker each target its own model service via provider:model identifiers, base URLs, and bearer-token headers. Those models shape what is remembered and how it is retrieved, so more compatible model endpoints directly benefit the pipeline.

Problem and proposed solution

I'm an engineer on the OrcaRouter team, and I'd like to propose adding OrcaRouter as an optional inference provider for PowerContext. It would not replace or change any existing provider. OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, so it can slot into the provider abstraction PowerContext already uses (see docs/en/development/pydantic-ai-inference.md): a workload would point at OrcaRouter with an OpenAI-compatible identifier such as openai-chat:<model> or openai:<model>, plus POWERCONTEXT_SERVER_INFERENCE_*_BASE_URL / *_HEADERS for the API key. Nothing here is implemented or tested yet — this is a proposal.

A few OrcaRouter capabilities look relevant to PowerContext users specifically:

• Many chat, reasoning, and embedding models through one endpoint and one API key, reducing the number of provider setups to manage.
• Automatic model routing with provider failover, so scheduled or long-running Memory/Handoff extraction jobs are less likely to stall on a single upstream outage.
• Usage tracking and per-project budgets, which fits PowerContext's guidance to enable generation-backed jobs only when their extra model cost is intended.

OrcaRouter is already integrated into open-source projects such as RAGFlow, Dify, goose, promptfoo, and models.dev / OpenCode; see https://www.orcarouter.ai/built-with.

Disclosure: OrcaRouter runs an optional open-source partner program through which approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. Participation is not a prerequisite for the integration, and I'm glad to follow any disclosure or governance requirements PowerContext has.

I'd welcome maintainers' thoughts on whether an OrcaRouter provider would be a useful addition, and I'd be happy to submit an implementation PR if you're open to it.

Alternatives considered

The least invasive route is pointing users at OrcaRouter through the existing OpenAI-compatible base-URL settings; a first-class named provider in the Pydantic AI layer could follow if maintainers prefer.

Are you willing to contribute to this feature?

• Yes, I am willing to contribute code, docs, or design feedback.

Start with docs/en/development/pydantic-ai-inference.md and inspect the existing Pydantic AI provider abstraction and POWERCONTEXT_SERVER_INFERENCE_*_BASE_URL / *_HEADERS settings. The issue is currently a proposal, so first confirm whether OpenAI-compatible configuration is sufficient or maintainers want a named provider; done requires an agreed implementation path and support for OrcaRouter.