replicatedConfirmation waits on an unwritten log key when a relocation loses to a newer version #3182

Problem

A transaction that requests replicatedConfirmation can wait on a log position that was never written. This happens when every confirmable write in it is a relocation that loses to a newer version.

_writeRelocate's commit handler returns early when precedesExistingVersion(...) < 0, but unlike the other write types it does not set write.skipped = true. The staging code then records appendedTo for that write, so confirmationTarget in DatabaseTransaction.ts picks the committed log key instead of falling back to the stored entry's version. Peers never acknowledge that key, so the caller waits until a later write replicates, or until the confirmation times out.

Found by the Codex reviewer while checking the description of Count only a record's residents toward replicatedConfirmation (#3148), which introduced the log-key target. Confirmed by reading resources/Table.ts (_writeRelocate) on main.

Scope

• Main only (merged 2026-10-11, milestone v5.4); no release carries it.
• Needs a transaction whose only confirmable writes are losing relocations, so the trigger is narrow.

Fix

Mark the losing relocation skipped before returning, as the delete path does, and check the other commit handlers for an early return that skips the same step. A regression test: a confirmed transaction whose only write is a losing relocation resolves against the stored entry instead of the log key.