Replication send loop: certification veto stays latched for the whole connection after a benign scan failure #1066

Follow-up from review of Recover a replication leg wedged at connected:true with no receive progress (harper-pro#815).

Problem

#815 adds a connection-scoped flag (sendLogBreakUnresolved in replication/replicationConnection.ts) that is set the moment the send loop observes a scan failure: a corruptFrameStop, failedLogs, or a boundary range's exactStartFailures. It is never cleared for the rest of the connection. While it is set, the send loop does not certify the peer's per-origin floors (originFloors), because a later clean drain of a replaced range cannot prove that the gap an earlier, discarded range left was delivered.

Two cases make this broader than necessary:

• A benign torn tail (the repaired, designed case) latches it, so floor certification stays off until the connection is rebuilt even though nothing was lost.
• A superseded send loop can latch it for its replacement, because its failure is observed before the superseded-subscription guard.

Consequence: more resend work after a reconnect than strictly needed. No data loss: withholding certification is the safe direction.

Suggested direction

Scope the veto to the range object that failed, and clear it only when a replacement range is proven to have delivered everything the failed range could have skipped (for example, after the replacement drains past the failed range's highest sent position for the affected log).

Review-Deferral: f985e3dfb3757c7b severity=nit category=unclassified
Review-Deferral: 2ec4882bc487dcb4 severity=minor category=unclassified