Add instrumentation for Google Vertex AI (@google-cloud/vertexai)

Start by reading the existing instrumentation under packages/server-utils/src/ai/google-genai/ and the integration wiring in src/integrations/google-genai.ts, then compare the Vertex AI SDK entry points named in the issue. Add the standalone integration under packages/server-utils/src/ai/google-vertexai/, wire it through src/integrations/google-vertexai.ts and getTracingIntegrations(), and cover generation, chat, streaming, model, token, and finish-reason attributes.

Add native gen-AI instrumentation for the standalone Google Vertex AI SDK, @google-cloud/vertexai (repo).

Coverage status / why this is a partial gap

Vertex is already reachable two ways today, so this is specifically about the standalone SDK:

• @google/genai (which we already instrument) can target the Vertex backend via vertexai: true — already covered.
• @ai-sdk/google-vertex (Vercel AI SDK provider, ~13.6M/mo) — covered by proxy through our vercel-ai integration.
• @google-cloud/vertexai standalone SDK — not covered. This issue tracks that path.

Relevance (npm)

• @google-cloud/vertexai: ~4.0M downloads/month (~33.7M last year). Slightly above its trailing-12-month run-rate, though Google is steering users toward the unified @google/genai SDK, so weigh this against the fact that the modern path is already instrumented.

Rough scope

• Add instrumentation logic under packages/server-utils/src/ai/google-vertexai/ and wire it up via src/integrations/google-vertexai.ts, registered in getTracingIntegrations() (per the AI-integration architecture; runtime packages re-export from @sentry/server-utils).
• Instrument VertexAI -> getGenerativeModel().generateContent() / generateContentStream() (and chat sessions), plus streaming.
• Emit gen_ai.* spans following the span attribute conventions (gen_ai.provider.name = google_vertex, request/response model, token usage, finish reasons). Much of the response/attribute shaping likely overlaps with the existing google-genai instrumentation and can be shared.
• Not OpenAI wire-compatible, so it needs its own instrumentation (can't reuse the openai-compatible shim).