fix(client): skip replayed message.appended / message.completed when the step's text run is already done

[iroiro147]

What

Second reducer-idempotency half of #1507. The first half (preserve approval-responded across input.requested replays) shipped separately; this one covers the duplicate-text class.

upsertRun previously appended a new part whenever the latest same-step run was done, with no deduplication. When the resume stream's cursor sits behind session.streamIndex (see the issue's root-cause trace), the turn stream re-delivers events the client already consumed — and the reducer appended a second done text part for the same stepIndex.

The reducer now checks: if the incoming text (or reasoning) snapshot is a prefix of the last done run's recorded text (including exact equality), the upsert is declined as a replay. New turns producing different text for the same step continue to append a new part — the text → tool call → more text multi-run pattern the reducer explicitly supports is preserved.

Why a prefix check (not exact equality)

message.appended snapshots are cumulative: each event carries messageSoFar for the full stream-prefix. A replayed mid-stream event therefore carries a strict prefix of the run's terminal text, never a suffix or disjoint string. The rule "skip when done-text startsWith incoming-text" matches exactly the replay shape, and nothing else.

What's not fixed here

The resume-from-stale-streamIndex bug in useEveAgent is a hook-level concern that requires touching ClientSession's #F/#i/#r internals; see the issue for the author's own breakdown. This patch makes the reducer itself idempotent so duplicate deliveries from any source (resume, reconnect, multi-session) are safe — a strict superset of what stale-streamIndex produces.

Tests

Adds two reducer tests:

1. Replay dedup — drives message.appended("Hel") → message.appended("Hello") → message.completed("Hello") twice, asserts a single done text part for the step, unchanged on second pass.
2. Multi-run preserved — two message.completed events with different text for the same stepIndex still produce two parts (["First response.", "Second response."]), confirming the prefix guard doesn't swallow legitimate new runs.

pnpm exec vitest run --config vitest.unit.config.ts src/client — 90/90 tests green (15 reducer + 75 adjacent).
pnpm exec tsc -p tsconfig.json --noEmit — clean.

Linked issue

Refs #1507 (second reducer branch; the hook-level resume-from-stale-streamIndex concern is out of scope here)

[vercel]

@iroiro147 is attempting to deploy a commit to the Vercel Team on Vercel.

A member of the Team first needs to authorize it.