Contract: do base-copy-acquired rows propagate onward over a live subscription? #930

The question

When node B acquires rows from node A through a bulk base-copy (rather than through the live
transaction stream), and node C holds a live subscription to B, are those acquired rows eligible to
propagate B → C?

This is a contract question, not a bug report. The investigation that raised it could not find the
answer stated anywhere — in code comments, in DESIGN.md, or in an existing issue — and the two
plausible answers have very different operational consequences:

• If they propagate, a base-copy is transitive: repairing B from A also repairs C, and a
  topology of chained subscriptions converges from one repair.
• If they do not, a base-copy is a leaf operation: repairing B leaves C still divergent, and an
  operator who repaired the node they were looking at may reasonably believe the cluster is whole
  when it is not.

Why this is being asked now

The investigation that produced this question started from a different hypothesis — that the
system database's gossip path explained an observed asymmetry — and falsified it: both arms
of the experiment came back numerically identical. What survived is the narrower contract question
above, which the experiment was not designed to answer and which no existing issue asks.

What this is NOT

Checked and confirmed distinct from the two nearest open issues:

• harper#2193 — now scoped as an observability gap for bounded base-copy resyncs; its data-loss angle moved to
  Replication base copy can silently drop a transaction that is in flight when a node joins #876 (in-flight writes delivered by neither the copy nor the audit tail), which Anchor the replication base copy on a log-order barrier instead of a timestamp #878 fixed by anchoring the
  copy on the last committed log entry (the earlier harper#2697 approach was dropped). Both concern what the
  receiver gets from its source, not what the receiver then forwards.
• harper-pro#641 — a cursor silently skipping writes during a write-conflict storm (data loss by
  non-delivery). Concerns the live stream, not base-copy-acquired rows.

Neither asks the onward-propagation question. Searched harper-pro for existing coverage
(isLeader, "propagate", several issue-search phrasings); the closest hits — #826
(mesh amplification) and #710 (add_node_back rewrite) — are unrelated.

What would close this

A stated contract, in DESIGN.md or equivalent, plus whichever of these the answer implies: a test
pinning the behaviour, or a documented operator note that a base-copy repair is not transitive and
downstream subscribers must be repaired individually.

— Claude Opus 5.5