Atomic rename temp file vs Deno.lockFile for retry-safe writes

A design needs to write a single output file with automatic retries and avoid duplicated or partial writes when multiple invocations overlap. The constraint is cross-platform consistency and no built-in atomic-write helper in the Deno standard library.

One documented approach is write-to-temp then Deno.rename. On POSIX systems rename is commonly atomic, which can make the final file appear only once. On Windows the atomicity guarantees for an existing target are less clear and may allow non-atomic replacement during a retry window.

The alternative is coordination with Deno.lockFile for process-level locking before writing. Locking requires explicit unlock and its availability varies by file system and file type, and a crashed retry can leave a lock or temp file behind.

With these trade-offs, the unresolved decision is whether rename-based atomicity across all supported platforms is sufficient for retry-without-duplication without application-level coordination.

Is Deno.rename guaranteed atomic on Windows when the target exists? Does Deno.lockFile provide reliable cross-process exclusion on network file systems? What guarantees exist for cleanup of temporary files after a failed retry?