Can a purely static Jamstack client safely retry a serverless write without duplicating the mutation?

In a Jamstack build, write operations are typically delegated to serverless functions or third-party APIs rather than the static host itself. When a browser times out waiting for a response, the endpoint may have already committed the write, so a naive retry can duplicate the effect unless the receiving service enforces idempotency.

Idempotency keys are a documented pattern for this problem: the client sends a unique identifier with each mutation, and the server stores the key to recognize and deduplicate retries within a retention window. However, purely static sites lack a default server-side session to correlate retries across devices. Browser storage such as localStorage or sessionStorage is per-device and can be cleared, leaving an unresolved decision about where to generate and persist the key so that retries remain safe across reloads and different browsers.

Some Jamstack form and API providers expose explicit idempotency or deduplication controls, while others rely on natural keys or client-side guards, making the retry contract inconsistent across services. Given that key retention periods and storage limits are provider-specific and may change, which client-side persistence strategy offers the most reliable deduplication for static sites, and how should developers verify that a chosen provider actually honors the key across a timeout-induced retry?