fix(vertexai): preserve non-ASCII in tool-call arguments JSON

[Humphrey (HumphreySun98)]

Description

Two sites in `langchain-google-vertexai` serialize tool-call arguments with bare `json.dumps(...)`. Python's `json` defaults to `ensure_ascii=True`, so every non-ASCII character is escaped to `\uXXXX`. CJK text, emoji, and accented characters in tool-call args end up unreadable in `AIMessage.additional_kwargs["function_call"]["arguments"]` (the `_parse_response_candidate` path used by `ChatVertexAI` / Gemini on Vertex) and in the OpenAI-style payload built for Llama Model Garden.

This mirrors the langchain-google-genai fix in #1804 (which addresses the same pattern on the genai side) and the convention already established in `langchain-openai`'s chat model and `langchain-core`'s `messages/utils.py:1810`.

Relevant issues

None filed for the vertexai sites specifically; this is the vertexai analog of the langchain-google-genai issue #1789 / PR #1804.

Type

🐛 Bug Fix

Changes

• `libs/vertexai/langchain_google_vertexai/chat_models.py`: pass `ensure_ascii=False` to the `json.dumps` that produces `function_call["arguments"]` in `_parse_response_candidate`.
• `libs/vertexai/langchain_google_vertexai/model_garden_maas/llama.py`: pass `ensure_ascii=False` to the `json.dumps` that serializes tool-call args into the OpenAI-style payload.
• `libs/vertexai/tests/unit_tests/test_chat_models.py`: add `test_parse_response_candidate_preserves_non_ascii_in_function_call_arguments` asserting on the raw string. The existing parametrized `test_parse_response_candidate` round-trips arguments through `json.loads` for equality and so was blind to the encoding difference.

Testing

```
$ uv run pytest libs/vertexai/tests/unit_tests/test_chat_models.py -k parse_response_candidate -q
..............
14 passed, 96 deselected in 6.48s
```

Reverting only the one-keyword `chat_models.py` change while keeping the new test makes the test fail (`assert "你好" in '{"text": "\\u4f60\\u597d", ...}'` → AssertionError), confirming the regression test pins the buggy behavior.

`ruff check` and `ruff format --check` pass on all three files.

Note

The fix is intentionally minimal — a single keyword in each of two `json.dumps` calls. No behavior changes for callers reading `tool_calls[i]["args"]` (which already round-trips through `parse_tool_calls` and so has always been a clean dict). The change only affects the legacy `additional_kwargs["function_call"]["arguments"]` string and the OpenAI-style `tool_calls[*].function.arguments` field.

Disclaimer: this PR was prepared with the assistance of an AI agent (Claude Code). All code and test changes were reviewed by the author before submission.

[Humphrey (HumphreySun98)]

Heads-up for reviewers: the langchain-google-vertexai-us (llm-integration-tests) red mark is unrelated to this PR.

This is the same Cloud Build live-API failure that's currently hitting my parallel vertexai PR #1820 (a one-line change to _thinking_in_params that purely swaps a string comparison — no path through which it could regress integration tests). It also matches the precedent of merged PR #1730, which shipped with the same red mark.

This PR only touches json.dumps(...) encoding in tool-call argument serialization paths; all GitHub Actions (build, lint, test 3.10–3.14, compile integration tests) are green.

Disclaimer: this comment was prepared with the assistance of an AI agent (Claude Code).