fix(client): don't stream text into an activity message with the same id

[TheSeydiCharyyev]

Description

Fixes #1350.

When a text message arrives under an id an activity message already holds, the TEXT_MESSAGE_* handlers match on id alone and write into the activity message. Its structured content object is replaced with the streamed string, so the message ends up as role: "activity" with content: "Hello, world!" — no longer a valid ActivityMessage — and the assistant's reply is never created as its own message. Reproduced on main with the repro from the issue:

before:  id=shared-message-id-123  role=activity  content="Hello, world!"
after:   id=shared-message-id-123  role=activity  content={"message":"Generating plan..."}

Message ids are unique across a conversation — every lookup in this file is a bare find on id — so an activity message under a text message's id means the producer reused the id. The client cannot guess the intent, and it should not silently corrupt the message it already holds.

The guard already exists in this file for the same situation. ACTIVITY_DELTA checks the role, warns, and returns when it lands on a non-activity message; resolveOrCreateAssistantMessage does the same for TOOL_CALL_START, warning and falling back rather than writing into whatever it found. The TEXT_MESSAGE_* handlers are the ones missing it. This PR adds the same check to them.

Note: ACTIVITY_SNAPSHOT is left alone. Its replace branch overwrites a non-activity message under the same id, which is intentional and covered by "replaces non-activity message when replace is true" and "does not alter non-activity message when replace is false". My first comment on the issue called the bug symmetric — that was wrong, and the correction is here.

Changes

• sdks/typescript/packages/client/src/apply/default.ts — TEXT_MESSAGE_START, TEXT_MESSAGE_CONTENT and TEXT_MESSAGE_END warn and skip when the id belongs to an activity message, instead of creating/appending/announcing over it.
• sdks/typescript/packages/client/src/apply/__tests__/default.activity.test.ts — new TEXT_MESSAGE_* against an activity message's id block: the activity message survives untouched, each of the three handlers warns, and text still streams normally when the id is free.
• docs/concepts/events.mdx — states that an activity messageId must not be reused by a text message and vice versa, and what a client should do if it is.

Verification

Windows 11, Node 22.17.1, pnpm 10.33.4:

• before: the activity message's content object is replaced by the text string and no assistant message exists
• after: the activity message keeps {message: "Generating plan..."}, the colliding text is dropped with a warning from each handler, and an uncolliding text message still streams into its own assistant message
• default.activity.test.ts — 30 tests pass (27 existing, unchanged, plus 3 new)
• the rest of the @ag-ui/client suite is unaffected

The pre-existing failure of esm-interop.test.ts on Windows is unrelated and is fixed separately in #2183.

[NathanTarbert]

Hey @TheSeydiCharyyev, this looks good.

The tests make the intent clear: activity message stays intact, each handler warns.

Only ask: confirm the branch is rebased on current main now that #2184 is merged (both touch default.ts), so we're reviewing against the final state.

Nice work. 🚀

[TheSeydiCharyyev]

Rebased on current main (0080f2a9). Worth noting the branch was already cut after #2184 landed, so its default.ts changes were in the base from the start — the rebase just makes that explicit against the current tip. No conflicts: default.ts, default.activity.test.ts and events.mdx haven't been touched on main since the branch point.

Verified on the rebased state: default.activity.test.ts is 30/30 green. Across the package it's 501/502 — the one failure is esm-interop.test.ts, the Windows-only ERR_UNSUPPORTED_ESM_URL_SCHEME issue fixed in #2183, unrelated to this change.

[NathanTarbert]

Thanks, I will get some eyes on it for you.