fix(postgres): lock missing items that TransactWriteItems checks or deletes

[yesyayen]

What

On PostgreSQL, two TransactWriteItems that each check or delete an item the other one creates could both commit. A ConditionCheck or Delete that found no row took no lock, so nothing stopped a concurrent create while the transaction still relied on the item being absent.

• reserve_missing_item() in crates/storage-postgres/src/data/transactions.rs runs when the ConditionCheck or Delete arm's SELECT ... FOR UPDATE finds no row. It inserts a key-only row with ON CONFLICT DO NOTHING and deletes it again in the same transaction. The key's unique index entry stays with the open transaction, so any insert of the key waits for it to end: TransactWriteItems, PutItem, UpdateItem and BatchWriteItem alike. No other transaction ever sees the row, and no stream record or index row comes from it.
• If the insert loses to a concurrent create, the op re-reads FOR UPDATE and uses the committed item: the check is evaluated against it, and the Delete removes it.
• If the placeholder delete removes anything other than one row, the transaction fails with an internal error instead of committing a key-only item.
• Put and Update need nothing new: their own insert already holds the key.
• Docs: the storage extension guide no longer says the PostgreSQL backend uses SERIALIZABLE. It, differences-from-dynamodb.md, the architecture guide, and the storage design now describe the key reservation.

This branch is stacked on #385: the first 6 commits are #385, and this PR adds the last 7.

SQLite runs one writer at a time, so it does not have this bug. MongoDB does, and a separate PR fixes it there.

Why

Found while checking TransactWriteItems isolation on PostgreSQL. Measured on 2026-10-05 on the head of #385: 100 rounds of the first shape and 40 of the others on PostgreSQL, 60 rounds per shape on Amazon DynamoDB.

Race	Amazon DynamoDB	PostgreSQL before this PR
[CC y absent, Put x] vs [CC x absent, Put y]	never both commit	both commit, 100 of 100
[Delete y if absent, Put x] vs [Delete x if absent, Put y]	never both commit	both commit, 40 of 40
[Delete y, Put x] vs [Delete x, Put y]	both commit only when one item remains	both commit and both items remain, 40 of 40
[Update x if absent, Put y] vs [Update y if absent, Put x]	never both commit	never both commit

The loser on Amazon DynamoDB gets TransactionConflict ("Transaction is ongoing for the item") or ConditionalCheckFailed.

Fixes: n/a, found by a concurrency probe, no issue filed

Result

• Conformance: the Amazon DynamoDB column was captured on 2026-10-05, and the new dual-target test passes there, 5 of 5.
• Tests: test_transact_absent_item_isolation.py (5 tests): on fix(postgres): lock TransactWriteItems items in key order, cancel on deadlock #385, 4 fail in 37 to 40 of 40 rounds each; on this branch, 5 of 5 pass in 3 of 3 runs. The conditional Update test is a control and passes on both. The test also passes on SQLite, and on MongoDB with its fix. 4 new PostgreSQL storage tests fail on fix(postgres): lock TransactWriteItems items in key order, cancel on deadlock #385 and pass here. cargo test --release --workspace: 1,234 passed.
• Performance: one client, 400 TransactWriteItems of 4 ConditionChecks on missing items and 1 Put, release build on one host over loopback: p50 4.2 to 4.3 ms on fix(postgres): lock TransactWriteItems items in key order, cancel on deadlock #385, 4.4 to 4.5 ms on this branch (2 runs each). Transactions that touch only existing items do not run the new code.

Testing done

• tests/test_transact_absent_item_isolation.py (new, dual-target): two transactions that each read an item the other one creates run at the same time, 40 rounds per shape: ConditionCheck on a hash table and on a table with a number sort key, conditional Delete, unconditional Delete, and conditional Update of a missing item. Every outcome is checked against the two serial orders, every failure must be a cancellation, and a run may see at most 5 HTTP 500s.
• crates/storage-postgres/tests/twi_conflict.rs (4 new tests, need EXTENDDB_TEST_PG_CONNECTION_STRING): an outside transaction holds an uncommitted insert of the item. A ConditionCheck must wait for it and then fail, and a Delete must wait and then remove the new item. A non-transactional PutItem of a key that a transaction checked as missing must wait for that transaction. A Delete that loses its reservation must remove the winner from the table and its LSI, and write one REMOVE stream record. The tests wait on lock-waiter counts, not on sleeps.
• Transaction, condition, batch, stream and GSI pytest suites (14 files) against a server built from this branch: no new failures. 2 GSI propagation-delay and 2 idempotency-scope tests also fail on fix(postgres): lock TransactWriteItems items in key order, cancel on deadlock #385.

cargo fmt --all -- --check
cargo clippy --all-targets -- -D warnings
cargo test --release --workspace                                        # 1,234 passed
cargo test --release -p extenddb-storage-postgres --test twi_conflict   # 8 of 8 in 10 of 10 runs, live PostgreSQL

Checklist

• I have read CONTRIBUTING.md
• All tests pass (cargo test --workspace)
• Code is formatted (cargo fmt --check)
• Clippy is clean (cargo clippy -- -W clippy::pedantic)
• I have added or updated tests for new functionality
• I have updated documentation if behavior changed
• Breaking changes are noted below (if any)
• If this changes the wire protocol, Storage trait, auth model, on-disk
  format, or public CLI surface, an RFC has been accepted or is linked
  below. Otherwise, an ADR captures the decision (link below).

ADR / RFC: n/a. Isolation inside one backend's write transaction; no wire, trait, auth, on-disk, or CLI change.

Merge order: after #385, which this branch is stacked on, and after the MongoDB fix for the same race, without which the new test fails on MongoDB.

Breaking changes

None.

---

By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache License 2.0 and I agree to the Developer Certificate of
Origin (DCO). See CONTRIBUTING.md for details.

[robinnsc]

Reviewed the commits on top of #385. The reservation mechanism itself reads correctly to me: the placeholder is inserted and deleted in the same transaction, the unique-index entry holds concurrent creates until commit or rollback, readers never see it, and the lost-race path re-reads FOR UPDATE and uses the winner. Postgres unit tests pass locally; I didn't have a live PG to run twi_conflict. A few smaller notes inline, plus one outside the diff:

crates/storage-sqlite/docs/design-decisions.md:28

Not in this diff, but since this PR corrects the SERIALIZABLE claim in manual 12, the SQLite design-decisions doc still says "Postgres achieves this with BEGIN ISOLATION LEVEL SERIALIZABLE". Might be worth updating in the same pass so the two docs don't disagree.