Replication send loop: each send-range repair resends every relayed origin's retained history from its session-start floor #1072

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

Problem

#815 repairs a stopped send range by rebuilding it in place. The rebuild tracks one named origin's own start bound. Any other origin sharing the merged range (for example a relayed origin) restarts from its session-start floor, or from zero when it is absent from startByLog (core starts a log missing from startByLog at zero). Each granted repair therefore resends that origin's retained history.

Repairs are paced at one per 30 s for a torn tail and one per 30 min for a mid-log break, and receivers absorb the duplicates, so this wastes bandwidth and CPU rather than losing data. The cost has not been measured. It grows with the relayed origin's retained history and write rate while a torn tail persists.

Suggested direction

Keep a per-nodeId high-water mark of what the session has sent from each origin, and seed each origin's rebuilt range from its own mark. The mark has to be append-order safe (see Replication base copy can silently drop a transaction that is in flight when a node joins (harper-pro#876)): advance it only past positions known to be committed and sent, never to the live maximum key.

A three-node relay regression test (origin A relayed through B to C, tear on B's session serving C) should land with it; a QA scenario for that shape is queued on #815.