commitFinished finalizes the txn-log entry even when RocksDB Commit() returns a hard error

Surfaced by the #694 review's domain pass; the behavior is pre-existing (preserved verbatim from the legacy libuv commit path) — #694 did not change it.

In the async-commit execute path, `store->commitFinished(...)` (which advances the committed-read watermark and makes the log entry visible, e.g. to replication) is gated on `committedPosition.logSequenceNumber > 0 && !status.IsBusy()` — not on `status.ok()`. If the txn-log `writeBatch` succeeded but `txn->Commit()` then fails with a hard non-Busy error (Aborted/IOError), the log entry is still finalized: the transaction log marks an entry committed/visible whose data never committed to RocksDB locally. A replication source could ship an entry it never applied.

Note the interaction with the abort path: `TransactionHandle::close()` calls `store->commitAborted(committedPosition)` for non-Committed transactions, which may compensate — the actual visibility window/semantics between `commitFinished` at execute time and `commitAborted` at close time needs tracing before changing the gate to `status.ok()` (the #668 IsBusy-retry hasLog semantics also touch this).

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Trace the async-commit execute path around store->commitFinished(...) and TransactionHandle::close(), including the commitAborted path. Compare the status handling with the #668 IsBusy-retry hasLog semantics and review the #694 discussion; done means the visibility and abort behavior for hard Commit() errors is explicitly resolved without exposing uncommitted data.

Written by the indexing model from the issue text.