feat: add Venice as LLM provider

[sabrinaaquino]

Adds Venice as an LLM provider alongside Gemini, Claude, and OpenAI. Venice is OpenAI-compatible and routes through api.venice.ai. If VENICE_API_KEY is set, it takes priority.

[JaeLeex]

Nice clean refactor on the OpenAI client caching — the _openai_clients dict keyed by base_url is a good pattern. A few issues to address before merge.

[JaeLeex]

Issue (High): Venice hijacks all providers when VENICE_API_KEY is set

This makes Venice take priority over every other provider regardless of the user's intent. If someone has both ANTHROPIC_API_KEY and VENICE_API_KEY set (common in dev environments), running --model claude-sonnet-4-20250514 silently routes to Venice instead of Anthropic directly.

Venice should only activate when explicitly chosen — not by env var sniffing.

Suggested fix:

def _detect_provider(model: str) -> str:
    if model.startswith("venice:"):
        return "venice"
    if model.startswith("gemini"):
        return "gemini"
    if model.startswith("claude"):
        return "claude"
    if model.startswith("gpt") or model.startswith("o1") or model.startswith("o3") or model.startswith("o4"):
        return "openai"
    # Venice as fallback for unknown models when key is available
    if os.environ.get("VENICE_API_KEY"):
        return "venice"
    return "gemini"

[JaeLeex]

Issue (Medium): Verify model names

openai-gpt-54-pro and zai-org-glm-5 don't appear to be real model identifiers. Are these Venice-specific proxy names? If so, please link to Venice's model catalog so we can verify. We don't want to advertise model names that don't resolve.

Also worth clarifying that claude-opus-4-6 here is Venice-proxied, not direct Anthropic API access.

[JaeLeex]

Nit: The Venice examples should use an explicit prefix (e.g. venice:claude-opus-4-6) to match the detection fix above. Bare claude-opus-4-6 would route to Anthropic without the prefix.