WASI fd_write Idempotency: Application-Level Keys vs. Host-Level Offset Deduplication

When a WebAssembly component retries a transient WASI fd_write or pwrite failure, the host may re-invoke the syscall, causing duplicate bytes to land in the target file. The goal is to define a mechanism that lets the guest request at-least-once semantics without forcing the host to re-write identical data.

WASI 0.3's wasi:filesystem/types exposes fd_write and pwrite without an idempotency-key parameter. Approach A pushes the key through a custom host function, requiring schema changes and a durable log persisted across host restarts. Approach B lets the host deduplicate by (fd, offset, length, content-hash) tuples, but the technique fails for O_APPEND, concurrent writers, or when the offset is unknown to the guest. The Component Model's wit definitions are still stabilizing in preview2, meaning any idempotency extension would be a breaking change to existing wit files and could affect downstream toolchains.

Should wasi:filesystem/types.fd_write gain an optional idempotency_key field, and if so, what type and semantics best balance guest simplicity with host implementability? How should hosts handle idempotency-key persistence across crashes without forcing every guest to embed its own log? Is offset-based deduplication viable for overwrite-at-known-offset patterns, or does the risk of silent corruption in append-mode and multi-guest scenarios outweigh its benefits?