provider proposal: Google Vertex AI integration

[stackbilt-admin]

Summary

Preliminary provider proposal: evaluate adding Google Vertex AI / Gemini-on-Vertex as a first-class provider to @stackbilt/llm-providers.

Why this came up

During OSS imagery generation for this repo, the text-to-image model hallucinated Vertex AI as an integrated provider. That is not currently true. The package currently supports OpenAI, Anthropic, Cloudflare Workers AI, Cerebras, Groq, and NVIDIA NIM.

Initial scope questions

• Should this be a generic VertexAIProvider, a Gemini-specific provider, or separate Google AI Studio vs Vertex AI integrations?
• What auth surface should be supported in OSS: service account credentials, ADC, workload identity, API key where applicable, or consumer-provided fetch/token hooks?
• Which model families should enter the catalog initially?
• Which capabilities are native and stable: streaming, tool/function calling, JSON/structured output, vision, usage accounting, safety settings, cache semantics?
• Should LLMProviders.fromEnv() auto-discover this provider, or should auth complexity require explicit config?

Preliminary acceptance criteria

• Verify current Vertex AI request/response/stream shapes against primary Google documentation or live fixtures before implementation.
• Add provider config type, factory wiring, catalog entries, capability metadata, and model drift tests.
• Add schema drift fixtures/tests for non-streaming and streaming responses.
• Add clear docs for auth setup and any unsupported surfaces.
• Keep imagery/marketing copy accurate: do not list Vertex AI as integrated until this ships.

Notes

This is not a bug in current runtime behavior. It is a product/package roadmap issue created to convert a hallucinated visual claim into an explicit tracking primitive.