A floor-only resume waiver does not apply beside an earlier-starting subscription #1257

Problem

The sender waives the oldest-retained-entry retention check for a floor-only resume start only when the subscription naming the sender holds the request's earliest start (replicationConnection.ts, floorStartHistory and the SUBSCRIPTION_REQUEST handler). The prune record covers every log of the database, so later starts in the same request are covered too; an earlier start is not, so the request falls back to the oldest-entry check and a young database still gets a base copy.

The case this leaves out is a failover self-catchup rider (subscriptionManager.ts attachSelfCatchupNode) whose start is earlier than the floor-only start. It does not occur on RocksDB today, the only engine with floor-only resumes: the rider attaches only with replication.failover on, and its start comes from lastTimeInAuditStore, which returns undefined on RocksDB (getKeys with reverse is unsupported there). A generation mismatch on the sender's own subscription still forces the copy regardless of the other starts.

The same scope rule leaves out two more shapes, both conservative: an unlisted origin replayed from below the floor-only start (its cursor less ORIGIN_CURSOR_OVERLAP_MS), and a request with no subscription naming the sender (a relay-only request, which has no floor-only start to waive). Each falls back to the oldest-entry check.

Possible direction

Judge the earlier start with the same prune record (isResumablePosition at that start, plus the margins floorStartHistory applies), once it is established that such a start lies inside the current database generation's history. If the self-catchup rider is meant to work on RocksDB, lastTimeInAuditStore needs a RocksDB implementation first.

Review-Deferral: bfe36b82e1485767 severity=minor category=correctness
Review-Deferral: 9431f0cacae25cd7 severity=minor category=correctness