fix(postgres): concurrent UpdateItem upserts creating one item must all succeed

[LeeroyHannigan]

What

Concurrent UpdateItem calls with no ConditionExpression racing to create the
same not-yet-existing item now all succeed, and each writer's update expression is
applied on top of whatever the previous writer committed.

Why

Closes #249.

Reproduced on this backend before changing anything, at the exact commit the
reporter cited (3961c63):

• 10 of 20 calls failed with ConditionalCheckFailedException across five trials
• four writers each setting a different attribute left an item holding only
  one of them, so three writers' data was lost outright
• sequential create-then-update was unaffected, which is why this only appears
  under concurrency

Measured against real DynamoDB in us-east-1 for comparison: six concurrent writers
on one brand-new key succeeded 6/6 across three trials, and four writers setting
four different attributes produced an item holding all four. The service serialises
writes to one item, and an UpdateItem without a condition is an upsert, so every
writer must succeed and each expression applies on top of the previous commit.

Root cause

Every read in this layer already uses SELECT ... FOR UPDATE, so writers to an item
that exists serialise correctly on the row lock. A row that does not exist yet
cannot be locked, so two writers could both take the insert path. The loser's
ON CONFLICT DO NOTHING affected no rows, and the code answered that with
ConditionFailed regardless of whether the caller ever supplied a condition.

The sibling put_item path already draws the distinction correctly, using
DO UPDATE for the unconditional case and DO NOTHING plus ConditionFailed only
for the conditional one. update_item had only the second shape.

The fix

The read-modify-write now sits in a bounded loop with a single locking read at its
head. On the first pass that read is the original one; after a lost race it is the
re-read that resolves the conflict.

Re-reading FOR UPDATE is what makes this terminate. ON CONFLICT DO NOTHING does
not wait for a concurrent uncommitted inserter, so a plain re-read can see nothing
at all, whereas the locking read blocks until the winner commits (returning its row)
or aborts (returning none, so the insert can be retried). The loser then re-applies
its update expression on top of the winner's item.

Attempts are capped at five. A retry can only be provoked by another writer
committing or rolling back the row, so exhausting the cap means something
pathological and returns an internal error rather than looping.

Deliberately not ON CONFLICT DO UPDATE SET item_data = EXCLUDED.item_data

That is the obvious one-line fix, it is what the issue suggests, and it is wrong
here. The losing writer computed its item from an empty base, so EXCLUDED
holds only the attributes its own expression set. Overwriting with it silently drops
whatever the winner set, which is exactly the data loss measured above, while
keeping every call successful. It is correct for PutItem, where blind overwrite is
the semantics, and it stays in place there and in the transactional helper.

Testing done

cargo test                                  # 422 integration, 0 failed, 0 filtered out
cargo test --no-default-features --features postgres   # 671 workspace, 0 failed
cargo fmt --all --check                     # clean
cargo clippy --all-targets --no-default-features --features postgres -- -D warnings   # clean

Run against a live Postgres 16 backend over HTTP, not in process.

Two tests added to tests/rust/src/concurrency.rs:

1. concurrent_unconditional_upserts_to_one_new_item_all_succeed_and_merge
   asserts the merge, not merely the absence of the error. This is deliberate: a
   test that only counted failures would pass against the EXCLUDED.item_data fix
   while data was being dropped.

   • Negative control: fails on the unpatched build with exactly the reported
     ConditionalCheckFailedException.
   • 20 consecutive passes on the fix, since one green run cannot distinguish
     deterministic from lucky.

2. only_one_racing_conditional_create_wins is a regression guard, not a bug
   demonstration, and the code comment says so because it is easy to misread: it
   passes both before and after. Re-evaluating a condition against the race winner
   produces the same answers either way, because attribute_exists fails against
   its empty base before reaching the insert and attribute_not_exists still fails
   when re-evaluated against the winner. I initially read this as a second defect
   and that was wrong; the test exists to prove the retry did not perturb either
   outcome.

One thing worth recording so nobody re-investigates it: three capacity_throttling
failures appeared mid-investigation. They were an artefact of running that suite
against a warm server immediately after the full run, and were proven unrelated by
an A/B on a fresh server, 7 passed both with and without the change.

Scope

• SQLite is unaffected. Its update_item serialises on a process-wide write lock
  and has no lost-race branch.
• tx_helpers.rs is unchanged. It uses a blind upsert, which is defensible inside
  the serialised transact path, where DynamoDB itself rejects concurrent transactions
  on one item with TransactionConflictException.

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. This restores documented DynamoDB behaviour on an existing
operation; no contract, trait, format or CLI change.

Breaking changes

None. Callers that previously received ConditionalCheckFailedException from an
unconditional UpdateItem were receiving an error the real service never returns,
so no correct client can depend on it.

---

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.