fix(model): normalize malformed streaming tool call fragments

[Alexxigang]

Summary

• normalize malformed OpenAI-compatible streaming tool-call fragments with a non-null tool name but no tool-call id
• prevent trailing argument chunks such as } from becoming a new synthetic streaming_ tool call
• add parser, formatter, and accumulation regression coverage for the malformed chunk shape reported in [Bug]:执行工具调用是，解析的参数发生异常（When executing the tool call, an exception occurred in the parsed parameters） #1216

Why this fix

Some OpenAI-compatible APIs can return the final argument fragment with name set even though id is null. The previous parser treated any non-empty name as a new tool call, generated a synthetic streaming_ id, and prevented ToolCallsAccumulator from merging the closing fragment back into the original call. The parser now recognizes that malformed named chunk as a fragment so the original call keeps complete JSON arguments.

Validation

• mvn -pl agentscope-core -Dtest=OpenAIChatFormatterTest,OpenAIStreamingToolCallTest,OpenAIResponseParserTest,ToolCallsAccumulatorTest,OpenAIChatModelTest test -q
• mvn -pl agentscope-core spotless:check -q

Fixes #1216

[codecov]

Codecov Report

❌ Patch coverage is 69.23077% with 4 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...pe/core/formatter/openai/OpenAIResponseParser.java	69.23%	1 Missing and 3 partials ⚠️

📢 Thoughts on this report? Let us know!

[Alexxigang]

Friendly ping when maintainers have time. The change is ready on my side, and I'm happy to make any follow-up adjustments if review feedback comes in. Thanks!

[Alexxigang]

Added targeted streaming edge-case coverage on top of this PR for missing-id first chunks, malformed complete JSON chunks, and thought-signature-only fragments.

Validation:

• mvn -pl agentscope-core '-Dtest=OpenAIResponseParserTest,OpenAIStreamingToolCallTest,OpenAIChatFormatterTest' test

[LearningGp]

The index field in the OpenAI streaming protocol is specifically designed to correlate multiple chunks of the same tool call. Wouldn't it be more appropriate to leverage this mechanism to address the issue?

[Alexxigang]

Friendly ping when maintainers have time. The branch is still ready on my side, including the added regression coverage, and I'm happy to make any follow-up adjustments if review feedback comes in. Thanks!

[Alexxigang]

Checked this against the current implementation before changing anything: index is already part of the correlation path in ToolCallsAccumulator.determineKey() as the last fallback after id, non-placeholder name, and lastToolCallKey.

The cases this PR is targeting are the ones where correlation alone still leaves us with a broken block:

• first/only chunk has no stable id, so downstream still needs a generated tool-call id
• the final assembled arguments string is malformed JSON, so we need to preserve raw content instead of dropping it on parse failure
• Gemini-style thought-signature-only fragments add metadata without advancing the normal name/args fields

So I agree index is the right mechanism for chunk grouping, and the current accumulator already uses it. The remaining fix here is about making the assembled ToolUseBlock still usable when the provider sends incomplete or malformed fragments even after grouping.

[Alexxigang]

Friendly follow-up on this one as well: the branch is still ready on my side with the regression coverage included, and I can adjust the implementation if you'd prefer a different direction around the streaming tool-call assembly path.

[LearningGp]

PTAL @chickenlj