Decide whether the audit log keeps one entry per key per transaction #3073

When one transaction writes the same key twice, the audit log gets two entries for that key with the same version, and both link to the same previous version. #1970 (fix for #1968) fixed the record/index orphan from this pattern but left the audit shape as it was.

Where

resources/Table.ts writeCommit calls recordUpdater (resources/RecordEncoder.ts ~:888) once per write, so each write to the key produces its own audit/txn-log entry stamped with the transaction's timestamp.

Why it needs a decision

Under the dual-clock model in #2412, write identity is (nodeId, first word) and auditStore.get(firstWord, tableId, id, nodeId) looks an entry up by it. Two entries for one key under one first word make that lookup ambiguous. Both also carry the same previousVersion, so a walk of the version chain sees a fork rather than a sequence.

Options:

1. One entry per key per transaction: coalesce at commit (the option Two writes to the same record in one transaction orphan the intermediate secondary-index entry #1968 raised).
2. Keep one entry per write and define the ordering between same-version entries (for example, log position) for replay, replication, and chain walks.

Not established

• Whether any consumer (replication send, replay, previousVersion chain walk, audit queries) currently misbehaves on the duplicate. This is a contract gap found while fixing Two writes to the same record in one transaction orphan the intermediate secondary-index entry #1968, not a reproduced failure.

— Claude Opus 5.5 (finding-triage)