Preserve origin record versions and transaction-log keys during replication

[kriszyp]

Replication frames carry two clocks with different jobs:

• version is the origin record's LWW version.
• txnLogKey is the transaction's position in the origin node's log.

Previously the frame/log-position value was named localTime in parts of the implementation, inherited from the deprecated LMDB model. This PR makes txnLogKey the canonical internal name. localTime remains only on pre-existing compatibility payloads such as listener/history and end_txn; it is no longer the conceptual name of the clock.

What changes

• The sender writes the origin txnLogKey in the existing frame header and carries the audit body's version separately.
• The receiver validates the frame's txnLogKey before any durable state moves.
• The RocksDB receiver applies the record at its origin version and commits it under the origin txnLogKey, then advances resume state and replication watermarks in the log-key domain.
• A dual-clock primary record retains an audit-head reference, so out-of-order reconciliation and per-record history enter the transaction log at txnLogKey rather than the record version.
• Full-copy rows recover that audit-head key when retained, so the copy/replay boundary remains in the log-key domain and replayed writes remain auditable on relays.
• If retention already removed the audit head, a full-copy row falls back to its bounded record clock. This is safe because the copied row is an auditless snapshot from before copyStartTime; the receiver does not persist its per-row frame key as a replay cursor. Audit read errors still fail the copy rather than masquerading as retention.
• Batch grouping, retention, residency reconstruction, and transaction completion use txnLogKey rather than the record version.
• Invalid frame log keys hold and reconnect the replication leg before any record or cursor is committed.
• The wire layout does not change; this clarifies and preserves the meaning of its existing fields.

This depends on Harper #2497, "Expose record version and txnLogKey as separate audit clocks", which supplies the core audit/read/apply contract and replay-safe log-key identity. The two PRs ship as one artifact.

Why preserve the origin log key

A source fill can have a backdated record version but a current transaction-log position. If a receiver keys that entry at its own receive time, every hop invents a new cursor identity. If it keys the entry at the record version, resume state moves into the LWW clock domain. Preserving the origin txnLogKey gives every relay the same durable write identity while preserving version for record ordering.

Verification

• Three-node O to R to T integration: 2 passing. A backdated source fill retains the same version and txnLogKey on every hop, then survives an unclean T restart and resume through R unchanged.
• Final post-rebase frame-key, copy-key, copy-metadata, and validation unit suites: 16 passing.
• npm run build emits successfully but exits on the repository's existing analytics Numeric/bigint, Promise.withResolvers, WebSocket _socket, and error-property type failures; no new error is attributable to this change.

Scope and follow-ups

Deprecated LMDB keeps its existing transaction-version apply and grouping behavior; the internal audit reader still calls its log position txnLogKey. A pre-existing relayed-resume duplicate-entry issue remains outside this naming and clock-preservation change.

Refs #790

_{Review-Coverage: authored=codex; ran=cursor-composer,gemini; declined=claude,cursor-grok,domain; rounds=19 @ 0c5976d}

_{Human-Review-Need: 4 @ 0c5976d}

[gemini-code-assist]

Code Review

This pull request separates the handling of the origin's log key and the record's version within replication frames, preventing issues where the two clocks were conflated (such as during backdated cache fills). It also introduces validation for incoming frame log keys to avoid poisoning resume cursors with corrupt values, backed by new integration and unit tests. The review feedback suggests adding a safety check to ensure replicationSharedStatus is defined before accessing it to prevent potential runtime errors, and validating lastSequenceIdReceived with Number.isFinite() to prevent NaN propagation into the transaction's local time.