[Enhancement]: Native Google Vertex AI provider (service-account auth)

[mrigankad]

Summary

Add a native Google Vertex AI provider (vertex) so users can authenticate with GCP project credentials instead of an API key. Today the only Google option, gemini (GEMINI_SERVER_URL=https://generativelanguage.googleapis.com), targets AI Studio and does not accept Vertex project/service-account credentials. Anthropic Claude-on-Vertex is likewise unsupported.

Motivated by #310, where a user could not configure Vertex AI keys. The current workaround is to front Vertex with a LiteLLM proxy and use the custom provider — functional but requires running extra infrastructure.

Goals

• Authenticate via GCP Application Default Credentials / a service-account JSON key, with explicit project ID and region/location.
• Support Gemini models on Vertex; ideally also Claude-on-Vertex (Anthropic models served through Vertex).

Non-goals

• Replacing the existing AI Studio gemini provider (kept as-is).
• Per-request dynamic credentials / multi-project routing (future work).

Proposed implementation

Follows the repo's documented "Adding a New LLM Provider" checklist (CLAUDE.md). Concrete touch points verified against main:

1. Provider impl — backend/pkg/providers/vertex/vertex.go implementing provider.Provider. The official genai/Vertex Go SDK exposes Gemini-on-Vertex; the existing backend/pkg/providers/gemini/gemini.go is the closest reference and the request-shaping logic may be largely reusable behind a Vertex transport/auth layer.
2. Constants — add ProviderVertex ProviderType = "vertex" and DefaultProviderNameVertex in backend/pkg/providers/provider/provider.go.
3. Registration — wire into DefaultProviderConfig, NewProvider, buildProviderFromConfig, GetProvider in backend/pkg/providers/providers.go.
4. REST validation — add vertex to the Valid() whitelist in backend/pkg/server/models/providers.go (without this the REST API returns 422).
5. Config — add env keys in backend/pkg/config/config.go, e.g.:
   • VERTEX_PROJECT_ID
   • VERTEX_LOCATION (e.g. us-central1)
   • VERTEX_CREDENTIALS_FILE (path to service-account JSON; fall back to ADC / GOOGLE_APPLICATION_CREDENTIALS when empty)
   • optionally VERTEX_SERVER_URL for regional/private endpoints
6. Migration — goose migration in backend/migrations/sql/ adding 'vertex' to the PROVIDER_TYPE enum, following the enum-swap pattern in 20260227_120000_add_cn_providers.sql (Up: recreate enum incl. vertex; Down: delete vertex rows then recreate without it).
7. Frontend — provider icon frontend/src/components/icons/vertex.tsx registered in provider-icon.tsx, plus settings-page wiring.
8. Docs/.env.example — document the new keys.

Open questions for maintainers

1. Adapter strategy — extend/parameterize the existing gemini adapter to support a Vertex transport+auth mode, or a fully separate vertex package? (Affects code reuse vs. clean separation.)
2. Scope — Gemini-on-Vertex only first, or include Claude-on-Vertex in the same provider? Claude-on-Vertex uses the Anthropic message schema, which may argue for routing it through the anthropic adapter with a Vertex auth/endpoint mode instead.
3. Auth surface — is service-account JSON file + ADC sufficient, or is workload-identity / bearer-token (mirroring the Bedrock multi-auth approach) also desired?
4. Web settings — should Vertex be configurable from the Settings UI like other providers, or env-only initially given the credential-file requirement?

I'm happy to implement this once direction on Q1–Q2 is confirmed. Note the DB migration + GCP auth flow are areas that will need maintainer review and GCP credentials to test end-to-end.

References

• How to provide Google Vertex AI API key in the .env file #310 (original Vertex AI request)
• CLAUDE.md → "Adding a New LLM Provider"
• LiteLLM Vertex docs: https://docs.litellm.ai/docs/providers/vertex