[Feature] Add Gemini 3 support via OpenRouter API

[yongkangc]

Summary

Add Google Gemini 3 as a provider option in Garcon, routing through the OpenRouter API (OpenAI-compatible).

Motivation

Garcon currently supports Claude, Codex, OpenCode, and Amp. Gemini 3 is a strong coding model but has no native CLI agent (unlike Claude Code or Codex). OpenRouter provides a unified, OpenAI-compatible API that can route to Gemini 3 (and other models) without needing a dedicated SDK — making it a lightweight integration path.

Current Architecture

• common/providers.ts defines the canonical provider list: claude | codex | opencode | amp
• Each provider has a CLI adapter in server/providers/ extending AbsProvider
• common/models.ts holds static model lists per provider
• Provider capabilities (fork, images) are declared in PROVIDER_CAPABILITIES

Proposed Approach

Option A: New openrouter provider (recommended)

Add a thin openrouter.ts provider adapter that:

1. Speaks the OpenRouter chat completions API (POST https://openrouter.ai/api/v1/chat/completions)
2. Streams responses via SSE (OpenRouter supports streaming)
3. Manages conversation history in-memory per session (no external CLI process)
4. Exposes Gemini 3 models in common/models.ts (e.g. google/gemini-3-pro, google/gemini-3-flash)
5. Supports tool use / function calling if OpenRouter relays it for Gemini 3

Changes required:

• common/providers.ts — add openrouter to PROVIDERS array and PROVIDER_CAPABILITIES
• common/models.ts — add OPENROUTER_MODELS with Gemini 3 variants
• server/providers/openrouter.ts — new provider adapter
• server/providers/openrouter-auth.ts — API key validation (OPENROUTER_API_KEY env var)
• server/providers/index.ts — wire into ProviderRegistry constructor and all fan-out methods
• server/providers/loaders/openrouter-history-loader.ts — history persistence
• web/ — add OpenRouter to provider picker UI, settings page for API key
• Auth status endpoint — add openrouter to AUTH_DISPATCHERS

Option B: Route through OpenCode

If OpenCode already supports OpenRouter as a backend, this could be a config-only change. Worth investigating but likely less flexible.

Configuration

OPENROUTER_API_KEY=sk-or-...

Optionally allow users to configure the API key in the Settings UI (like existing provider auth).

Model List (initial)

• google/gemini-3-pro (default)
• google/gemini-3-flash
• Could expose other OpenRouter models later (making this a general-purpose OpenRouter integration)

Notes

• OpenRouter API is OpenAI-compatible, so existing OpenAI SDK patterns may apply
• Tool/function calling support depends on what OpenRouter passes through for each model
• This could later generalize into a broader "API provider" that supports any OpenRouter-available model