Second assistant reply does not render after a connection-generation change (rebind or remount)

[omridevk]

Found while implementing #326 / PR #349, reproduced on the pre-fix build, so this is pre-existing and not caused by the ws cut-over.

After a connection-generation change — handle.rebind(...) or unmount+remount — a subsequent turn's chat.send completes normally over the new transport, but the transcript still shows only ONE assistant message: getByText(ASSISTANT_TEXT) stays at count 1 instead of 2.

Evidence:

• Reproduced via the rebind path on the pre-fix build (no connection close involved), so it is not the unmount/close work in PR feat(ws): browser client cut-over to /rpc-ws (#326, PR 3/3 of #314) #349.
• No test in the repo has ever asserted a second reply across a generation change: packages/embed/test/rebind.it.test.ts and forced-drop.it.test.ts both assert rpc completion only. That is why it was never caught.
• PR feat(ws): browser client cut-over to /rpc-ws (#326, PR 3/3 of #314) #349's new lifecycle tests likewise assert the rpc-level outcome, deliberately, rather than encoding this bug as expected.

Suspects to investigate (evidence-first, no patching): the chat query/collection being rebuilt on connectionGeneration change and re-seeding from a server snapshot; the fake harness's constant runId: 'scripted' masking or causing it in tests (see the note on #326 — a real harness mints a distinct runId per turn, so confirm against a real harness before concluding); or the transcript store keying messages by a value that collides after the rebuild.

Note the second bullet matters for triage: if it only reproduces with the scripted fake harness, this is a test-fixture defect, not a product bug. That distinction should be the first thing established.

[omridevk]

Partial contradiction — narrowing this ticket. While merging origin/main into the #349 branch, main's version of packages/embed/test/rebind.it.test.ts turned out to already assert exactly this: it extends a rebind test with ASSISTANT_TEXT count 2, SECOND_USER_TEXT count 1, USER_TEXT count 1 after the rebind. Those assertions were carried into the merged file and pass (rebind suite 4/4 green on the merge commit 34cc0955).

So: a second assistant reply DOES render after handle.rebind(...) on current main + the #349 branch. The originally-reported symptom must therefore be either (a) specific to the unmount/remount path rather than rebind, (b) specific to the scripted fake harness's constant runId under some particular sequence, or (c) an artifact of the diagnostic scaffolding used when it was observed.

Next step for whoever picks this up: reproduce on the REMOUNT path specifically, with the merged rebind assertions as the known-good control. If it does not reproduce there either, close this as not-a-bug and note the fake-harness runId caveat on #326 instead.