WASI key-value store `increment` operations are not strictly idempotent across multiple backends

The WASI wasi:keyvalue/atomics interface describes atomic operations as all-or-nothing: if a fault causes an atomic operation to fail, the caller should observe either that it completed successfully or that it did nothing.

Spin’s remote KV backends rely on each service’s native update primitive. This can leave ambiguous outcomes:

• Azure Cosmos DB uses PATCH increment; if Cosmos commits the PATCH but the response is lost, retrying may apply the increment again because PATCH increment has no native idempotency token.
• Redis uses INCR; if Redis applies the increment but the response is lost, retrying the command may also apply the increment again.
• Avoiding retries prevents duplicate application, but Spin may still return an error even though the value changed.

This leaves a gap between the strict WASI fault semantics and what Spin can currently guarantee for remote KV stores. Fully closing it would likely require an internal exactly-once protocol, such as recording an operation id/result atomically with the counter update and reconciling ambiguous outcomes before returning. This is indeed not easy to implement, so I am documenting it as an issue for now.

Start with the WASI wasi:keyvalue/atomics interface and Spin’s remote KV handling for Azure Cosmos DB and Redis. Assess whether an exactly-once operation-id/result protocol can resolve ambiguous retries without duplicate increments; done would require closing that semantic gap or documenting the remaining limitation.