fix(gemini): never send a functionCall-opening turn with no preceding user turn

[hartmark]

Problem

Gemini rejects any contents[] that opens with a functionCall-bearing "model" turn:

[400]: Please ensure that function call turn comes immediately after a user turn or after a function response turn.

Observed live on the default combo: a request retried this identical error against every one of 3-5 Gemini variants tried (each one rejects the same corrupted history identically), before the new identical-error circuit breaker (#13338) correctly stopped it fast instead of exhausting all 11 fallback targets over ~13 minutes.

Root cause

mergeConsecutiveSameRoleContents (9router#2191) already guarantees strict user/model alternation for every contents[] index >= 1 (Gemini only ever uses those two roles in contents, and the merge collapses any adjacent same-role pair). That leaves exactly one way to violate Gemini's rule: history that opens with a functionCall-bearing turn, with nothing before it at all.

This is reachable whenever the true leading user turn goes missing from a request's history while a mid-conversation assistant tool-call turn survives — e.g. continuation reconstruction, context compression, or a truncated client history. I was not able to pin down the exact upstream trigger with certainty from static analysis alone (flagged as a known gap in #13338); this fix closes the resulting Gemini-side failure regardless of which upstream path produces it.

Fix

ensureHistoryDoesNotOpenWithFunctionCall (openai-to-gemini/helpers.ts): if contents[0] is a "model" turn containing a functionCall part, prepend a minimal synthetic "user" turn. Applied right after the existing same-role merge in both the OpenAI→Gemini and Claude→Gemini request paths (siblings that share the same helper).

Testing

• New unit tests in translator-gemini-consecutive-role-2191.test.ts: the helper directly (prepends when needed, leaves valid/empty input alone), plus a full-translator test reproducing the exact reported failure shape (history opening on an assistant tool-call turn) and asserting contents[0].role is always "user".
• Confirmed the new tests fail without the fix (TypeError: ... is not a function / missing leading-role assertion).
• Two existing translator-claude-to-gemini.test.ts fixtures intentionally started their messages[] on an assistant tool_use with no leading user turn (unit-testing field mapping in isolation, never exercised against real Gemini) — updated their content-index assertions to account for the now-correct synthetic leading turn; no behavior change to what they're actually testing.
• Full sibling suite (207 tests across every openai-to-gemini/claude-to-gemini test file) passes.
• tsc -p tsconfig.typecheck-core.json clean.

🤖 Generated with Claude Code

[diegosouzapw]

Ran your new tests locally at the PR head — 27/27 pass, including the full-translator
reproduction of the reported failure shape. Clean, well-scoped fix. Only thing missing is a
changelog.d/ fragment — could you add one? Once that's in this looks ready to merge.

[hartmark]

Added the changelog fragment — changelog.d/fixes/13573-gemini-leading-functioncall-turn.md, verified with check:changelog-integrity. Ready to merge from my side.