Standardize idempotency-key handling across Increase, Column, and Modern Treasury

Steps

1. For Increase, generate a pre-allocated unique string (up to 200 characters) per creation call and send it as the Idempotency-Key header; check the Idempotent-Replayed response header to detect when a call returned a previously created object instead of a new one.
2. For Column, send a unique client-generated Idempotency-Key header per request; a repeated key on the same endpoint returns the original created object (e.g., transfer) instead of creating a duplicate.
3. For Modern Treasury, pass a unique idempotency key in the request headers; the key and result are retained for a bounded window (24 hours), and repeated calls within that window replay the original response.
4. Choose a consistent key-generation strategy across all three — e.g., deterministic keys derived from your own internal object ID such as an invoice or payment order ID — so retries after process crashes or timeouts remain safe.
5. Build retry logic that always reuses the same idempotency key for a given logical operation, treating a network-level failure with no response as 'retry with the same key,' not 'assume failure and mint a new key.'