feat(vertex): add Google Vertex AI provider for Gemini (OAuth2)

[teknium1]

Summary

Adds Google Vertex AI as a first-class provider for Gemini models via Vertex's OpenAI-compatible endpoint. The missing piece behind the recurring requests (#13484, #12639, #56259) was authentication: Vertex has no static API key — every request needs a short-lived OAuth2 access token (~1h TTL) minted from a service-account JSON or Application Default Credentials (ADC), which is why pasting a token into a custom provider dies mid-session. Hermes now mints and auto-refreshes those tokens.

Salvages and modernizes #8427 by @slawt onto current main: rewired from the legacy PROVIDER_REGISTRY path to the current provider-profile architecture, moved non-secret config out of .env into config.yaml, and added per-turn 401 token refresh the original lacked.

Changes

• agent/vertex_adapter.py — OAuth2 token minting + refresh-on-expiry (5-min margin), ADC→service-account fallback, global vs regional endpoint URLs. Config precedence: env var > config.yaml > default.
• plugins/model-providers/vertex/ — provider profile (auth_type="vertex"), reuses Gemini's extra_body.google.thinking_config translation.
• hermes_cli/runtime_provider.py — vertex short-circuit before the credential pool so a credentials-file path is never mistaken for a static API key; mints a fresh token + computes base_url per resolve.
• run_agent.py + agent/conversation_loop.py — _try_refresh_vertex_client_credentials() re-mints the token and rebuilds the client on a mid-session 401, so a long-lived gateway agent survives token expiry.
• agent/auxiliary_client.py — vertex auth_type branch for side-LLM tasks.
• hermes_cli/config.py — vertex.project_id / vertex.region (non-secret, bridged to env); credential path stays in .env (VERTEX_CREDENTIALS_PATH).
• setup wizard + model picker — dedicated _model_flow_vertex, curated google/gemini-* model list, --provider choices, aliases (google-vertex, vertex-ai, gcp-vertex).
• pricing / metadata — Vertex prices off the gemini docs snapshot; endpoint host auto-maps to the vertex provider (no context-length probe spam).
• tools/lazy_deps.py + pyproject.toml [vertex] — google-auth, opt-in (not in [all]).
• docs — guides/google-vertex.md + providers page; tests for adapter + runtime resolution.

Validation

	Result
tests/agent/test_vertex_adapter.py + tests/hermes_cli/test_vertex_provider.py + test_turn_retry_state.py	27/27 passing
tests/hermes_cli/test_runtime_provider_resolution.py + test_model_normalize.py	222/222 passing (no regressions)
tests/hermes_cli/test_models.py + test_usage_pricing.py + test_model_metadata.py	206/206 passing
E2E (real imports, mocked google-auth)	token mint, config→env bridge, alias resolution, regional endpoint, thinking_config, friendly AuthError all pass
ruff	clean

Verified against Google's official Vertex OpenAI-compatibility docs (endpoint shape, api_key=credentials.token, 1h token TTL, extra_body.google.thinking_config).

Closes the Gemini-via-Vertex request cluster. Claude-via-Vertex (AnthropicVertex SDK, #55742/#6491/#3569) is a separate family, out of scope here.

Infographic

[alt-glitch]

This was generated by AI during triage.

Related: salvage of #8427 (@slawt, earliest/canonical) onto current main. Competing OPEN native-Vertex-Gemini cluster for #13484: #8427, #16010, #29611 (Express Mode api-key variant), #36253 (prior rewrite). Not a duplicate — a maintainer should pick the canonical implementation from the cluster.

[EgorLu]

Great to see this land so quickly! My PR #55742 covers the complementary piece: Claude on Vertex via the AnthropicVertex SDK. Both share the vertex provider name and plugin path, so they'll conflict on a few files. Happy to rebase onto this once it merges.