fix(vouchers): reserve claims atomically before reward dispatch

docs/superpowers/evidence/2026-09-05-voucher-reservation.md

@@ -0,0 +1,22 @@
+# Voucher claim reservation
+
+The public redemption action now serializes claims on the selected voucher row.
+It validates amount, capacity and expiration, locks the duplicate-claim read,
+inserts the used row, increments usage and stores the audit intent in one transaction.
+No reward dispatch occurs until the transaction resolves successfully. A commit
+acknowledgment failure prevents dispatch and returns a correlation reference.
+
+The reward transport remains the existing sendCurrency implementation. A false
+or thrown result is unconfirmed, not proof that no increment occurred. Such a
+claim stays consumed and receives a partial audit outcome. It must not be blindly
+replayed or refunded; staff can inspect the correlated intent and final outcome.
+A completion-audit failure after successful dispatch does not report failed delivery.
+
+This does not guarantee exactly-once emulator processing, introduce automatic
+reward recovery, or claim that database reservation and external dispatch are
+one distributed transaction. No migration or live data change is performed.
+
+Tests exercise the real action and generated Drizzle SQL with controlled database,
+session, audit and currency transports. They prove boundary ordering and error
+mapping, not actual multi-connection MariaDB locking or emulator acceptance.
+The initial regression run had nine expected failures before implementation.