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

## 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:
```json
{ "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.