feat: OpenAI-compatible /v1 client and provider routing

[quiet-node]

Overview

This PR makes Thuki's bundled inference engine reachable and adds support for OpenAI-compatible servers: a generic OpenAI-compatible /v1 chat client, a new openai provider kind, and routing of every LLM consumer (chat, search, title generation, warmup, capabilities) by the active provider's kind. Stacked on the engine-runner PR (#217). Fresh installs still default to Ollama at this point in the stack; the default flips in #219.

What changed

• openai provider kind: [[inference.providers]] entries with kind = "openai" (label, base_url, model, and a manual vision flag). API keys are stored write-only in the macOS Keychain (keychain.rs), never in config.toml and never returned over IPC.
• Legacy-config pin: configs written before the providers list existed are pinned to Ollama on load, regardless of what the default is or becomes. Existing users keep their working setup; only fresh installs follow the compiled default.
• /v1 SSE client (openai.rs): streaming chat with content parts, bounded SSE line buffering, cancellation, and typed error classification (EngineUnreachable, EngineStartFailed, model-not-found and auth variants).
• Routing by kind (commands.rs): ask_model dispatches builtin chat through the engine runner plus /v1, Ollama through native /api/chat, and openai through /v1 against the provider's base_url. Search and title generation run through a provider-kind LlmTransport; warmup, eviction, the VRAM poller, and capability detection all branch by kind, with a /props probe gating vision for builtin models.

How it works

The active provider is resolved from managed config per request; builtin requests first await ensure_loaded on the engine runner, then stream from the local server like any other /v1 endpoint. Capabilities are cached per (provider_id, model). All three kinds emit the same StreamChunk channel contract, so the frontend streaming path is provider-agnostic.

Testing

Both gates exit 0 at the branch head. The /v1 client is covered against mock servers (SSE framing, oversized lines, missing done markers, cancellation, auth and 404 classification); routing, warmup, and capability branching are covered per kind in backend unit tests.