fix(ai-sdk): emit tool-call events for OpenRouter compatibility

[0xMink]

Closes #11419

Summary

• processAiSdkStreamPart() silently ignored AI SDK tool-call events, relying entirely on tool-input-start/delta/end lifecycle events for tool delivery. @openrouter/ai-sdk-provider v2.1.1 does not emit tool-input-end for incrementally streamed tool calls, and emits only tool-call with no tool-input-* events for flush-path calls. This caused tool calls to be silently dropped for all OpenRouter-proxied models.
• Now emits tool-call as a tool_call chunk with string passthrough (avoids double-encoding when upstream JSON parse fails) and ?? {} fallback for undefined input.
• Added deduplication in Task.ts tool_call handler: skips tools already finalized via streaming path, replaces in-flight partial tools, pushes new blocks for flush-only path. All three OpenRouter streaming paths are now handled correctly.

Test plan

• Existing: 87 ai-sdk tests, 10 duplicate-tool-use-ids tests, 38 Task tests, 12 NativeToolCallParser tests -- all passing
• New: 3 tests for tool-call emission (object input, undefined input, string passthrough)
• New: 5 tests for tool_call dedup ordering (skip finalized, replace partial, flush-only push, tool_call-before-end ordering, mixed paths)
• 155 total tests passing, 4 skipped (pre-existing)

[roomote]

Rooviewer   See task

All previous issues resolved. Test updates in 90a3ee2 correctly align provider specs with the new tool-call emission behavior. No new issues found. LGTM.

• Dedup check in tool_call handler only matches tool_use blocks, missing mcp_tool_use -- can produce duplicate MCP tool blocks when both streaming and tool-call events arrive
• Missing text block finalization before pushing tool_use in flush-only path -- delays tool presentation until stream-end cleanup

Previous reviews

• 381faee: Review #1
• d176bf6: Review #2

_{Mention @roomote in a comment to request specific changes to this pull request or fix all unresolved issues.}

[roomote]

The dedup check only matches block.type === "tool_use", but NativeToolCallParser.finalizeStreamingToolCall() returns McpToolUse (type "mcp_tool_use") for dynamic MCP tools (mcp--serverName--toolName). When such a tool is already finalized via the streaming path, the block has type: "mcp_tool_use" and streamingToolCallIndices has been cleaned up, so both guards miss it. parseToolCall then returns a second McpToolUse which gets pushed as a duplicate. This only triggers when MCP tools are proxied through OpenRouter and both streaming events and tool-call are emitted for the same call.

Suggested change

	const alreadyPresent = this.assistantMessageContent.some(
	(block) =>
	block.type === "tool_use" &&
	!block.partial &&
	(block as any).id === chunk.id,
	)
	const alreadyPresent = this.assistantMessageContent.some(
	(block) =>
	(block.type === "tool_use" || block.type === "mcp_tool_use") &&
	!block.partial &&
	(block as any).id === chunk.id,
	)

_{Fix it with Roo Code or mention @roomote and request a fix.}

[0xMink]

Acknowledged — both issues addressed in 381faee:

1. Extended the alreadyPresent guard to include mcp_tool_use blocks, preventing duplicates when MCP tools finalize via the streaming path
2. Added partial text block finalization in the flush-only tool_call path (mirroring tool_call_start behavior) to avoid delaying tool presentation

Regression tests added for both scenarios (17/17 passing in duplicate-tool-use-ids suite, 128/128+4 skipped across ai-sdk and Task suites).

[0xMink]

Pushed CI fix 90a3ee2: updated provider test suites (DeepSeek, Mistral, Moonshot, OpenRouter) to expect tool_call chunk emission. Local: 107/107 passing across those suites.

[0xMink]

CI green. All review feedback addressed across 3 commits. Broad Unicode/control-char scan clean (no bidi, zero-width, BOM, soft hyphen, or formatting chars). Ready for re-review.