Think: reply renders twice after a tool approval (continuation start chunk not stamped with message id)

Finding: In an external report on cloudflare/agents (issue #2503, https://github.com/cloudflare/agents/issues/2503), a Think agent using @cloudflare/think 0.20.0, agents 0.26.0, ai 7.0.127 and @ai-sdk/react 4.0.130 shows the resumed reply twice in the client after a tool approval. This is an external report only; KFA has not reproduced it. Symptom and conditions (reported): The reporter used an OpenAI-compatible chat provider via createOpenAI with .chat(model), so start chunks carry no messageId. They had one server tool with needsApproval: true, and a client using useAgent and useAgentChat from @cloudflare/think/react, approving with addToolApprovalResponse. After approval, the client messages held two assistant messages with the same text: the original id and a new client-side id. Reloading showed the reply once, because the stored transcript has it once. The approved tool call could also appear in both messages because the continuation re-sends tool-output-available (https://github.com/cloudflare/agents/issues/2503). Captured frame shape (reported, abridged): the continuation emits a start chunk flagged continuation and replay with no messageId, then tool-output-available, text chunks and finish, then the persisted message list, then done (https://github.com/cloudflare/agents/issues/2503). Hypothesized cause (not maintainer-confirmed): The reporter points to Think._alignStreamStartId, which stamps the accumulator id onto start chunks only when the stream is not a continuation. For a tool-approval continuation that does not extend the leaf assistant message, the StreamAccumulator reportedly gets a new id, Think persists the reply under it, and the client, receiving a start without messageId, builds its own id on AI SDK v7. The two ids never reconcile. This is the reporter's reading of the code, not confirmed by a maintainer. Workaround (reported, not verified by KFA): The reporter says overriding _alignStreamStartId per instance, so it also stamps continuation start chunks that lack a messageId, removed the duplicate in their tests. They also say the duplicated tool part can be filtered on the client by de-duplicating tool parts on toolCallId across messages. The override patches a private method, so it is fragile (https://github.com/cloudflare/agents/issues/2503). Status: The issue is open with no comments supplied. A suggested fix is described in the issue text, but no fix commit or released fix is cited in the supplied sources. The issue links the separate, closed #1876 as a different path (recovery continuation duplicating a message). Other providers, versions and clients are untested in the report.