fix(replication): prevent out-of-order full update from reverting newer record

[kriszyp]

Summary

In the out-of-order resequencing path in resources/Table.ts (precedesExisting <= 0), when audit is enabled and the audit walk finds no succeeding updates to resequence around, a full update fell through to the shared commit line and stored the older record over the newer one (recordToStore = recordUpdate) — leaving the cluster permanently non-convergent.

This skips the losing full update instead: the existing record is newer, so the older update is superseded. It uses a bare return (no writeCommit) to match the existing superseded-by-newer-put branch a few lines above, so no audit record is written referencing this losing update's pre-saved blobs.

Purpose

Fixes #1170. Reproduced via deployment tracking: a burst of same-key full puts replicates to a loaded peer, commits out of order, and the row gets stuck at a non-terminal status forever (origin + other peers converge; one peer does not). Surfaced as the intermittent harper-pro deployTrackingReplication.test.mjs failure on main.

Where to look — please scrutinize

This is a hot, critical replication path; it deserves careful core review:

• Blob lifecycle (the subtle bit). Codex flagged that write.skipped = true + writeCommit(false) with audit on would write an audit entry referencing the losing update's blobs and then clean them up (orphaning them). The fix avoids this by using a bare return — matching the existing put/delete supersede branch at the top of this block. Please confirm this is the correct discard path and that no blob/audit bookkeeping is skipped that the existing supersede branch relies on.
• Reachability. The guard triggers only when fullUpdate && !incrementalUpdateToApply at the end of the audit branch — i.e. an out-of-order full update with no reconstructable succeeding updates. Worth confirming there is no legitimate case where we should still write here.

Open items for the reviewer

• No local regression test yet. This needs a test that drives out-of-order same-key full puts and asserts the newest survives; I could not run the resources/replication suites locally (no native DB build in this environment). Guidance on the right harness (or a follow-up commit) welcome.
• Verified to compile + lint; not yet run against the replication suite locally — relying on CI.

Cross-model review: Codex (raised the blob concern above; addressed).

🤖 Generated by Claude (Opus 4.x) per the Harper engineering DLC.

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!

[claude]

Reviewed; no blockers found.

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!