payments: the reply that never comes, and the idempotency key

[sajonaro]

Stacked on #7 (base deployment).

Adds payments/: one order going through authorize, capture, settle, ship, refund and cancel, over a wire that loses replies, with a shop that retries. The pair is with and without an idempotency key.

• With the key: never charged twice, never left charged for a cancelled order, and every order can still reach an end. Exit 0.
• Without it: authorize → send-capture → capture → lose-reply → send-capture → capture-again, and the customer is charged twice. derive double-charged shows those orders looking normal in every stage, including settled-and-shipped, refunded and cancelled.
• Also without it: a void overtakes the capture on the wire, finds nothing to refund, and the capture lands afterwards. The key is what lets a cancellation refer to a request that has not arrived yet.
• writ failed my first draft of the safe file, key and all. cancel was allowed whenever the shop had not captured, so a capture still in flight landed after the cancellation. cancel now voids at the processor under the same key. The README tells the story.

Cross-check: 52 → 56 properties (54 compared). ./run-tests.sh all: 314 checks, 0 failed.

🤖 Generated with Claude Code

[sajonaro]

Superseded: reached main through #10.