fix: preserve operation order in TransactionWriteSet

[polyatail]

Fixes #254

Problem

TransactionWriteSet stores saves/puts/deletes/checks in four separate sets, and toTransactionWriteRequest emits them grouped by kind — all saves, then puts, then deletes, then checks — regardless of the order the caller added them.

DynamoDB returns a List<CancellationReason> on TransactionCanceledException that is positionally aligned with the TransactWriteItems in the submitted request. Because Tempest reorders the items by kind, a caller who interleaves operations (e.g. delete(B); save(A)) cannot reliably map a returned cancellation reason back to the operation that triggered it.

Fix

• Introduce a WriteOperation sealed type (Save/Put/Delete/Check) and track the caller's insertion order in TransactionWriteSet.Builder.
• Expose it as TransactionWriteSet.operations, populated in build(). It is kept out of the data class constructor to preserve the public equals/copy/destructuring signature; direct construction falls back to the historical save → put → delete → check order.
• Replay operations in both toTransactionWriteRequest (covers the sync and async paths) and describeOperations, so the submitted request items — and the failure message — line up with the returned cancellation reasons.
• Builder.addAll now replays the source builder's operations in order rather than re-adding bucket-by-bucket.

Scoped to tempest2 (AWS SDK v2).

Test plan

• New transactionWritePreservesOperationOrderAcrossKinds adds a delete before a save and asserts both TransactionWriteSet.operations and the cancellation failure message reflect insertion order (Delete, Save) — fails under the old grouped behavior, passes now.
• Existing LogicalDbTransactionTest, AsyncLogicalDbTransactionTest, WritingPagerTest, and AsyncWritingPagerTest pass.

🤖 Generated with Claude Code