Atomic file replacement with a durable rename.

Write a private temp sibling, fsync it, rename it over the destination, then fsync the parent directory so the rename itself survives a crash. Either the old contents or the new ones are visible at every instant; a reader never sees a truncated file.

Two failures, not one

The point of this crate is that the two ways it can fail mean different things, and callers legitimately treat them differently:

• [AtomicWriteError::NotCommitted] — the destination was never touched and the temp file is cleaned up. The caller simply failed.
• [AtomicWriteError::DurabilityUncertain] — the new contents are already visible, but the directory fsync confirming the rename did not complete, so a power loss could still resurrect the old ones.

A catalog that must not lie about what it persisted treats the second as an error; a record store that would rather keep the record and warn treats it as a warning. So this crate reports which happened and lets the caller decide, rather than picking one policy for everyone.