Replication send loop: skip-timer SEQUENCE_ID_UPDATE can advertise a sequence whose frame is not yet sent #1068

Follow-up from review of Recover a replication leg wedged at connected:true with no receive progress (harper-pro#815). The code in question is unchanged by that PR; two independent review models reported it.

Problem

In the send loop in replication/replicationConnection.ts, skipAuditRecord arms a timer (skippedMessageSequenceUpdateTimer) that, after SKIPPED_MESSAGE_SEQUENCE_UPDATE_DELAY, sends [SEQUENCE_ID_UPDATE, currentSequenceId]. currentSequenceId is advanced to a record's key when the record is processed (if (key > currentSequenceId) currentSequenceId = key;), not when the record's frame has been written to the socket. The receiver persists a received SEQUENCE_ID_UPDATE as its resume cursor for the sender.

If a record has been processed (so currentSequenceId already covers it) but its own frame has not yet been sent, and the timer fires, the receiver is told that sequence is complete. If the socket drops before that frame goes out, the reconnect resumes past the transaction and it is not resent by the live path.

Confidence: medium. The ordering is visible in the code; I have not reproduced a lost record. What would settle it: a test that holds a record frame behind an awaited step (blob read or residency check) while the skip timer fires, then drops the socket and checks the receiver's cursor against the delivered records.

Suggested direction

Advertise only a sequence that has been handed to ws.send: track a sentSequenceId-style high-water mark that is advanced after the frame is sent, and have the timer use it (or min of it and currentSequenceId when no frame is pending).

Review-Deferral: 23b1ec50574b140e severity=major category=data-integrity