Add isolated transactional Query RMW workload

[KirillKurdyukov]

Summary

Builds on #69 and adds a separate native Query transactional RMW workload.
Four writers contend on shared counters in bounded rounds. A serializable
transaction records a stable logical ID with each counter update, making
ordinary SDK retries safe after an ambiguous commit. Final validation compares
the exact independently retained IDs, payloads, counter values and versions.

Each process owns both tables for its complete lifecycle. Cleanup drops only
acknowledged creations. Final SDK/data failures remain nonzero, and metrics count
actual outer SDK attempts, including acquisition and commit-triggered retries.
The existing basic workloads, SDK retry policy and dependencies are unchanged.

Verification

• 25 focused tests pass, including failed-CREATE ownership and real SDK retry
  control flow. Exact source-publication gate: APPROVE.
• Original source Dockerfile/helper builds both own-SDK images. Real simultaneous
  current/baseline processes exit 0 with distinct tables; short cleanup preserves
  the longer peer. Actual OTLP metrics are received.
• Five independently acknowledged corruption/final-SDK cases each exit 1.
• After four commits actually persisted, substituting UNDETERMINED for one held
  successful reply recovers through the ordinary SDK and exits 0 without applying
  an ID twice. Independent before/after SQL snapshots verify the invariant.

The ambiguity case uses protocol substitution, not physical response loss or
server chaos. Both native images use the same SDK library revision; this is not
a two-version benchmark. JDBC/JPA RMW and OS-signal shutdown are not claimed.

The separate SDK consumer PR will pin this exact examples revision and add the
ordinary SLO matrix row. Hosted SLO acceptance is not claimed by these local
source/image receipts.