A dropped record of a filtered table marks an origin-wide route hole that nothing clears #1213

Problem

A record dropped because its table does not replicate, or because the receive route excludes it, calls recordReplicationHole. That marks a route hole for the record's origin (replication/replicationConnection.ts, the route branch of recordReplicationHole). The hole covers every table of the origin, not only the filtered one, and nothing ever clears it. A later full-coverage copy re-asserts it, because restoreCompletedCopyPass re-queues hole for every origin in holedOrigins. So the origin stays non-checkpoint-grade, and checkpoint capture stays refused under strict availability, until the origin's database generation changes.

It fails closed. The cost is checkpoint availability, reached when a sender's table list is stale or older and still forwards a filtered table.

Possible direction

Do not count a record of a table this route deliberately filters as a hole (nothing was lost that the route owed), or scope the hole to the table and clear it on a completed full-coverage copy.

Raised by the cross-model review on harper-pro#1092 and deferred there: pre-existing route-hole semantics.

Review-Deferral: 32c9a64bdb09

Review-Deferral: f066f9fe71f9148a severity=minor category=reliability