[albertominetti]

Issue for this PR

Closes #56725

Type of change

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

What does this PR do?

A transcript GET can finish after newer assistant events have reached the client. The old snapshot then replaces the live message and makes its answer disappear. During each transcript read, this tracks message IDs changed by live events. When the response arrives, changed rows keep their live state, untouched history comes from the response, and removed rows stay removed.

How did you verify your code works?

• The new delayed-read regression test failed before the fix because the live assistant message disappeared.
• cd packages/client && bun test --conditions=browser --rerun-each 10 test/solid-transcript-race.test.ts test/solid-inbox-race.test.ts: 70 passed.
• Focused client tests, including stale-tool reconciliation and in-flight eviction, passed. bun typecheck and git diff --check passed.
• The full packages/client suite had the same 13 failures on the base branch and this change. Four were toMatchObject assertions against Solid store proxies. The repository-wide check was also blocked by lint findings outside these files and an unavailable ast-grep binary.

Screenshots / recordings

Not applicable to this cache race. The regression test shows the message before and after the delayed response.

Checklist

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

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

[opencode-agent]

The fix works: I reproduced the delayed-read problem from #56725 on the base branch and it is gone with this change.

I ran the bot's reproduction script on both checkouts. On the base, the old history replaces the live assistant message and the reply is lost. With this change the message stays and finishes with Hello world and finish: "stop". The full packages/client suite has the same 13 failures on the base as with this change, so the four toMatchObject failures you mentioned already fail on the base. The type check passes.

What I checked in the code:

• Change tracking lasts for one read and is cleaned up in finally. createSync runs reads of the same session one after another, so two reads never share it.
• Rows removed by a revert or a retraction while the read is pending are not brought back.
• Pending submissions and admitted user rows are kept as before.
• Rows changed by live events keep their place in the fetched history.

Public API: unchanged. messageChanges and its helpers are internal to createData.

No blocking concerns. The regression test is one focused case without timers.

Related: #56726