Feature: OrcaRouter provider for conduit generate

Conduit is a Go data streaming tool that positions itself as the Kafka Connect replacement for moving data between production data stores - no JVM required. The README and roadmap show how deliberately operations are treated as design: pipelines are goroutine-connected building blocks that preserve record order and propagate acknowledgements only once every destination has confirmed.

What makes this relevant to OrcaRouter is `conduit generate`, which turns a plain-English request into a pipeline config already passed through `validate`. The provider package is explicit about "no default vendor": anthropic, openai, and ollama are peers, and `Resolve` refuses to silently pick among them. Engineers and agents who lean on `generate` would gain more model choice and control over cost and reliability from an optional OrcaRouter peer - nothing existing changes.

I'm an engineer on the OrcaRouter team, and I'd like to propose adding OrcaRouter as an optional `conduit generate` provider. OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, so it fits Conduit's existing provider seam: the `openai` adapter already wraps the vendored `go-openai` client and exposes a `BaseURL` field on the adapter, which is the natural pattern an OrcaRouter adapter would follow. Adding a provider touches the same small surface - a name in `provider.go`, env-var candidacy plus a `newProvider` branch in `cmd/conduit/root/generate/generate.go`, and flag/docs mentions. This is a proposal only; no code has been written or tested.

A few OrcaRouter capabilities map well onto `generate`:
- Model choice and routing: chat and reasoning models from several upstream providers through one endpoint, with automatic model routing and provider failover.
- Prompt caching: retries resend the same large grounded system context built from `llms-full.txt`, so caching makes repeated attempts cheaper.
- Usage tracking and budgets: `generate` already reports `tokensUsed` in `--json`, and per-key usage and budget visibility helps teams that run `generate` in CI or through agents.

OrcaRouter is already integrated into open-source projects such as Dify, goose, and promptfoo, so there is precedent in this ecosystem. One transparent note: OrcaRouter has an optional open-source partner program in which approved OSS projects receive a 5% revenue share from usage attributed to their integration. Participation is not a prerequisite for integrating, and I'm glad to follow Conduit's governance and disclosure expectations. See https://www.orcarouter.ai/built-with for current integrations.

Would you be open to an OrcaRouter provider for `conduit generate`? If so, I'd be glad to submit an implementation PR once you've weighed in on the approach.

Start with provider.go and cmd/conduit/root/generate/generate.go, then compare the existing openai adapter and its BaseURL handling. Confirm the provider seam, environment-variable candidacy, newProvider branch, and flag/documentation surfaces before implementing. Done means OrcaRouter is an optional, explicitly selectable provider without changing existing providers; add or update tests where the repository’s provider coverage indicates.

Written by the indexing model from the issue text.