fix(ai): map TOO_MANY_TOOL_CALLS to an error stop reason

[rsaryev]

Summary

mapStopReason throws on a Gemini response that finishes with TOO_MANY_TOOL_CALLS.

@google/genai@2.21.0 added the member to FinishReason. The exhaustive switch in google-shared.ts does not list it, so the call falls through to the default branch and throws Unhandled stop reason: TOO_MANY_TOOL_CALLS instead of returning a stop reason. It is grouped with MALFORMED_FUNCTION_CALL and UNEXPECTED_TOOL_CALL, the other tool-call failures, and maps to "error".

The same member is added to the FinishReason mock in google-raw-stop-reason.test.ts, which keeps its own copy of the enum.

This also unblocks npm run check on a clean checkout: tsgo --noEmit currently reports this as its only error, because reason is not never in the default branch.

Testing

• npm run check — passes; before this change it fails on google-shared.ts(402,10)
• npx vitest --run in packages/ai — 120 files, 1062 passed
• npx vitest --run test/google-raw-stop-reason.test.ts — 8 passed

[gaoanze888]

The production mapping is correct: @google/genai@2.21.0 defines TOO_MANY_TOOL_CALLS as a terminal tool-call failure, and both Google Generative AI and Vertex use this shared mapper. The exact head also restores npm run check, and the existing Google stop-reason suite passes 8/8.

One test gap remains: the test diff only adds TOO_MANY_TOOL_CALLS to the mocked enum. No test sets googleGenAiMock.finishReason to that value, so the suite still passes if the production case is removed. Please add a parameterized regression over the existing adapters table that asserts, for both Google and Vertex:

• stopReason === "error"
• rawStopReason === "TOO_MANY_TOOL_CALLS"
• the provider error message retains that reason

This is a two-line production fix for a dependency-enum addition, so the regression should directly exercise the newly handled value rather than only making the mock compile.

This comment is AI-generated by /wr

[gaoanze888]

Rechecked the new exact head 16fb21a5823c. The production enum mapping is still correct and CI is green, but the requested behavioral regression is still missing: the only test change adds TOO_MANY_TOOL_CALLS to the mocked enum. No test assigns that finish reason or asserts the adapter result. Removing the production case FinishReason.TOO_MANY_TOOL_CALLS therefore still leaves the changed suite green. Please add the direct Google + Vertex adapter assertions from the previous review (stopReason, rawStopReason, and retained error reason).