fix(tui): keep one row when a message is re-sent with the same id - #51033

Issue for this PR

Fixes #50945

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

The TUI sync store finds messages by time.created + id. When a prompt reuses an existing messageID, the server re-emits message.updated for the same id with a new time.created. The lookup misses, so the handler splices in a second row, and because parts are keyed by message id, both rows render the same content.

The message.updated handler now looks up an existing row by id first:

• same time.created: reconcile in place (same as before)
• time.created changed: remove the old row and re-insert it at its creation-time position, so the ordering from fix(tui): order messages by creation time #40994 is kept
• new id: unchanged binary-search insert

The parts store is untouched.

How did you verify your code works?

Added a regression test in packages/tui/test/cli/cmd/tui/sync-live-hydration.test.tsx. It sends msg_x at t=10, msg_y at t=30, then msg_x again at t=50, and expects one msg_x row, ordered [msg_y, msg_x], with time.created === 50.

• cd packages/tui && bun test test/cli/cmd/tui: 24 pass, 0 fail
• cd packages/tui && bun run typecheck: clean
• With the original sync.tsx, the new test fails (6 pass, 1 fail) because the duplicate row appears

Screenshots / recordings

N/A. This is a state-store change, covered by the test above.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR