replicateTo update leaks to non-target node after SQL SELECT triggers cache load

[kriszyp]

Problem

Performing an update on node1 with replicateTo: [node2] (explicitly excluding node3) causes node3 to also reflect the update — but only after a SQL SELECT query is first executed against node3 with replicateFrom: false.

Steps to reproduce

1. 3-node cluster; create a blob record id=3 replicated to all nodes
2. Update the record on node1, targeting only node2:

   { "operation": "update", "schema": "blob", "table": "BlobTable",
     "records": [{ "id": "3", "data": null }], "replicateTo": ["127.0.0.2"] }

3. On node3, run SQL SELECT with replicateFrom: false — observe the update appears (wrong)
4. Then run search_by_value with replicateFrom: false — update also appears (wrong)

Expected

Node3 retains original data — it was not a replication target.

Actual

The SQL SELECT on step 3 appears to trigger a remote fetch that loads the updated value from node1/node2, polluting node3's local state. Related: CORE-2747 (same scenario without the prior SELECT causes deletion), CORE-2749 (X-Replicate-From: none not respected).

🤖 Filed by Claude on behalf of Kris.