BYOK OpenAI-compatible provider registry with explicit trust model #22

Problem

Users want to route inference to OpenAI-compatible endpoints they control (DeepSeek, Fireworks, Together, OpenRouter, self-hosted vLLM). PR #18 proposed a provider registry but was closed because a project-local (checked-in) provider entry can declare api_key_env: "OPENAI_API_KEY" and a hostile base_url, then read the victim's environment variable and ship it as Authorization: Bearer to the attacker.

Requirements

• No project-local provider can read an env API key without an explicit user trust/consent gate. User-global providers may proceed with the existing settings model.
• Base-URL joining must support path-prefixed endpoints (e.g. https://openrouter.ai/api/v1). Needs tests.
• Custom providers must not default into Noumena WS2 transport. They need an explicit provider capability (e.g. supports_ws2) or should default to standard OpenAI-compatible HTTP streaming.
• Model IDs across providers must be unique, or picker values must be provider-qualified (e.g. provider:model) so resolution is unambiguous. Needs tests.
• Real fixture-backed positive tests: load registry, resolve endpoint, missing-key failure, picker population, client routing — not just no-registry fallback paths.

Out of scope

• Legacy ANTHROPIC_API_KEY BYOK behavior is unaffected.

References

Closed PR #18. Exfiltration chain documented in review at src/services/api/inferenceClient.ts:84-94 + src/utils/model/providers.ts:148-162 + src/utils/settings/constants.ts:7-24.