Per-originating-node transaction log partitioning (dependent on new transaction log format)

Maintain a per-originating-node-id partition within the transaction log, so replicated writes from node A and writes originating on the local node are tracked in separate sequences.

## Why

- Per-node transaction logs enable efficient selective catch-up: a new or restarting node can request only the transactions it missed from a specific origin, rather than scanning a global log.
- Conflict detection and resolution can be scoped to per-node streams.
- Per-node audit trails are cleaner for debugging replication issues.

## Design note (from Jira)

> "This may only be feasible in our new transaction log system with rocksdb-js."

This is gated on the new transaction log format being built in [CORE-2992](https://harperdb.atlassian.net/browse/CORE-2992) ("Create new transaction entry format"). File this to be scheduled once that lands.

## Acceptance criteria (once gate is met)

- Each replication transaction carries its originating node ID.
- The transaction log can be queried/iterated per-origin node.
- `cluster_status` / replication sync check can use per-node log position.

## Status

Not Ready — dependent on CORE-2992 completing.

---

Jira fields: **Feature Type:** Tech Debt · **Business Impact:** Operational efficiency *(both suggested)*

🤖 Filed by Claude on behalf of Kris.