[joshdchang]

Summary

• preserve row-bearing messages when a cached response is replayed for a previously acknowledged cursor
• suppress only the duplicate up-to-date control message while the tracker advances to the live cursor
• add a regression test and document the replay invariant in the TypeScript client specification

Root cause

The replay transition was represented as suppressBatch, and the client returned before publishing the entire response. A valid replay response can contain both data messages and the duplicate up-to-date marker, so this discarded rows together with the marker.

Fix

Represent the transition as suppressUpToDate, run the normal snapshot-tracker filtering, and remove only up-to-date messages before notifying subscribers. The client still avoids an empty subscriber callback when the response contains only the suppressed marker.

Fixes #4722.

Verification

• regression test fails on current main before the fix and passes after it
• corepack pnpm exec vitest --config vitest.unit.config.ts --run (438 tests)
• corepack pnpm run typecheck
• corepack pnpm run stylecheck
• Prettier check and git diff --check

[alco]

Thanks for the fix, @joshdchang — suppressing only the up-to-date marker and keeping the data messages is the right change, and it's going in.

To land it I've rebased your commit onto current main (kept as-is, with your authorship) and stacked a few follow-ups on top, opened as #4782 which supersedes this PR:

• LSN bookkeeping ordering. main now feeds global_last_seen_lsn from each up-to-date into the snapshot tracker inside the same filter. With your early return false ahead of that, a suppressed up-to-date would skip snapshot retirement. Moved the check after the LSN update so suppression only affects delivery to subscribers.
• Annotated the C9 test and spec entry as pinning a state-machine invariant rather than a server scenario. While tracing when the branch actually fires I found it can't against a conforming server: electric-cursor is only set on live=true responses, the client only sends live=true from LiveState, and ReplayingState is only entered around a non-live request. The same synthetic fixture shape (cursor headers on non-live responses) is what the original tracker tests from Fix multiple renders from cached up-to-date messages on page refresh #3358 use, which is why it wasn't obvious. Details in the new PR's description.
• Removed if (messagesToProcess.length === 0) return. It's a behaviour change outside replay mode too — a batch whose every change is rejected by the snapshot tracker previously produced a #publish([]) and with the guard produces nothing — so the new PR keeps the pre-existing behaviour. If you'd like to reintroduce it, you're welcome to comment on the rationale and implications over there and we can take it from there.

Closing this in favour of #4782.