fix(ai): prevent duplicate tool parts in tool-input-available handler

[pawaca]

Summary

Follow-up to #12774 which fixed the same duplicate-part bug in the tool-input-error handler.

The tool-input-available handler has the same bug: it uses chunk.dynamic directly to decide whether to call updateDynamicToolPart or updateToolPart, without first checking if there's already an existing part for the same toolCallId. This causes a duplicate when:

1. tool-input-start creates a static tool-{name} part (dynamic is undefined/false)
2. tool-input-available arrives with dynamic: true (from parseToolCall's NoSuchToolError catch)
3. updateDynamicToolPart doesn't find an existing dynamic-tool part, so it creates a new one — resulting in two parts for the same toolCallId

Real-world impact: sessions become permanently broken when the model calls a non-existent tool, because the duplicate tool_use IDs cause API rejection on every subsequent request.

The fix applies the same pattern already used in the tool-input-error case: look up the existing part by toolCallId and use its type to decide the update path, falling back to chunk.dynamic only when no existing part is found.

Closes #12772

Test plan

• Added regression test tool input available with dynamic flag mismatch (mirrors the existing tool input error with dynamic flag mismatch test from fix(ai): Don't create duplicate tool parts when models call non-existent tools #12774)
• Test asserts exactly one part exists for the toolCallId (no duplicate)
• Test asserts the static tool type from tool-input-start is preserved
• All 97 existing tests in process-ui-message-stream.test.ts continue to pass