fix(replication): don't let an out-of-order full update revert a newer record

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

Skip the losing full update instead — the existing record is newer, so this
older update is superseded. Uses a bare return (no writeCommit) to match the
superseded-by-newer-put branch above, so no audit record is written referencing
this losing update's pre-saved blobs.

Reproduced via deployment-tracking: a burst of same-key full puts commits out of
order on a loaded peer and the row gets stuck at a non-terminal status.

Fixes #1170

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

Author: kriszyp

resources/Table.ts

@@ -1973,6 +1973,19 @@ export function makeTable(options) {
 								);
 								if (!incrementalUpdateToApply) return writeCommit(false); // if all changes are overwritten, nothing left to do
 							}
+							if (fullUpdate && !incrementalUpdateToApply && precedesExisting < 0) {
+								// Out-of-order full update whose audit walk found no succeeding updates to
+								// resequence around: the existing record is strictly newer (precedesExisting < 0),
+								// so this older full update is superseded. Falling through to the shared commit
+								// below would set recordToStore = recordUpdate and revert the newer record. Bare
+								// return (no writeCommit) matches the superseded-by-newer-put branch above so no
+								// audit record is written referencing this losing update's pre-saved blobs.
+								// Gated on precedesExisting < 0 (not <= 0) so a same-transaction put-after-delete —
+								// which arrives as a tie (precedesExisting === 0) with no committed audit yet —
+								// still falls through and applies. (harperdb/harper#1170)
+								write.skipped = true;
+								return;
+							}
 						} else if (fullUpdate) {
 							// if no audit, we can't accurately do incremental updates, so we just assume the last update
 							// was the same type. Assuming a full update this record update loses and there are no changes —