fix(replication): close on inbound message-handler errors instead of swallowing them (#440)

[kriszyp]

Summary

Lands the first safety item of workstream #440 (epic #430 Theme B/F): an error escaping onWSMessage — the inbound handler in replicateOverWS — was logged and swallowed, silently dropping the rest of the failed frame while later frames kept applying and confirming higher sequence ids: a permanent, undetected gap on the receiver. The catch now calls closeOnInboundMessageError, which latches inbound processing off before closing (frames already queued on the messageProcessing chain must not commit past the hole; the peer can still deliver frames until the close handshake completes) and closes with 1011 as a transient protocol close, so the normal retry path reconnects and resumes from the last durable cursor. A deterministic poison frame becomes a visible, backed-off reconnect loop instead of silent loss (escalation budget = W2 #432).

Follow-up commit from cross-model review: the inner per-record decode catch's log line dereferenced tableDecoder.decoder unguarded, so an unknown tableId threw a secondary TypeError from the logger itself — masking the original error and escaping to the outer catch by accident. Now guarded, restoring the intended skip-and-log semantics with truthful diagnostics.

Where to look

• Behavior change: anything that throws/rejects out of the inbound handler now cycles the connection instead of being swallowed. The review traced the awaited paths under the outer try (isSkippableLeadingDuplicate store read, waitForDrain, frame decode) — routine/transient cases either have inner catches or only reject on substantive failure/teardown (where the latch is already set and close is a no-op). If you know of an error class in this path that is routine under normal operation, that's the thing to veto.
• Deliberately deferred residual (please confirm you agree): a per-record value decode failure is still skip-and-logged by the inner decodeBlobsWithWrites catch, and maxBatchVersion still advances past the skipped record — the same silent-gap class, now explicitly tracked in Replication W11: Code organization, protocol versioning & decode-loop safety #440 with W2 Replication W2: Cursor correctness & divergence detection #432 (it's the #1163/#1453 structure-fork lineage, so closing there has real blast radius and deserves its own change).
• closeOnInboundMessageError is extracted + unit-tested per the file's pure-decision-helper idiom (latch-before-close ordering pinned by test).

Cross-model review (Codex + Gemini + domain adjudication) found no blockers; both significant findings are addressed or explicitly deferred as above. Not user-facing; no docs change needed.

Generated by an LLM (Claude Fable 5), reviewed per the Harper DLC.

[gemini-code-assist]

Code Review

This pull request introduces robust error handling for replication connections over WebSockets by implementing closeOnInboundMessageError. This function ensures that inbound processing is halted and the connection is closed with a transient error code (1011) when an unhandled error occurs, preventing silent data loss. Additionally, it guards against TypeErrors when logging decoding errors by using optional chaining on tableDecoder. The feedback suggests further strengthening this error handling by making the logger dependency optional to prevent secondary crashes, and improving the log output formatting when tableDecoder is undefined to avoid string-concatenating undefined values.

[claude]

Reviewed; no blockers found.