Assess whether Table.ts appendedAuditEntry retry-dedup guards are dead code after the TryAgain publish-gate fix

Follow-up from #1823 / rocksdb-js#710 (cross-model review recommendation).

#1696 added per-write `appendedAuditEntry` / `stagedOwnAuditEntry` guards in `Table.ts` (≈2016, 2142, 2205, set in `DatabaseTransaction.save()`): a write whose prior failed attempt appended its own audit entry must not treat that orphaned entry as "already applied" in the retry dedup lookups.

Their motivating premise was that a failed attempt's audit entry was *queryable* during the retry — true under the old rocksdb-js `!IsBusy` publish gate, which published entries on a failed `TryAgain` commit. rocksdb-js ≥2.5.0 publishes only on a real commit, so a failed attempt's entry should never be visible to the retry's dedup lookups, for `ERR_BUSY` and `ERR_TRY_AGAIN` alike (both now recommit the same transaction).

Task: trace whether any remaining path can make a write's own staged entry visible to its retry (e.g. keyed lookup reading uncommitted, walk over `additionalAuditRefs`, multi-round recommit edge cases). If none, remove the guards and their test scaffolding; if some remain, narrow the comments to the real residual case. The adjudicated review judged the guards harmless-but-likely-redundant — do not remove without this analysis.

*KrAIs, via Claude*