feat(local): reliable file writes for LocalFileSystem

[jgiannuzzi]

Which issue does this PR close?

Closes #661.

Rationale for this change

See issue.

What changes are included in this PR?

• Add close_file() helper that calls libc::close() (Unix) / CloseHandle (Windows) directly and propagates errors, instead of relying on File::drop(). Note that this uses unsafe, like in the platforms' respective drop() implementations.
• Add with_sync_on_close(bool) builder method on LocalFileSystem that calls File::sync_all() before closing, providing stronger durability guarantees for network filesystems.
• Apply both to the put and put_multipart (via LocalUpload) code paths.
• Add libc (Unix) and windows-sys (Windows) as optional dependencies behind the fs feature for their respective platforms.
• Duplicate the existing integration test to also run with sync_on_close(true). Note that this doesn't "do" anything and is just there to validate that the additional behaviour does not create issues.
• Add unit test verifying close_file detects EBADF when the file descriptor is closed behind Rust's back. This is just to validate that close_file properly returns the OS error.

Are there any user-facing changes?

New public API: LocalFileSystem::with_sync_on_close(bool) -> Self. Default is false (no behaviour change for existing users).

Close errors are now detected and propagated as Error::UnableToCopyDataToFile. Previously these were silently ignored. This is a correctness improvement but could surface errors that were previously hidden.

[jgiannuzzi]

Hi @crepererum, could you please take a look at this change? Thanks!

[crepererum]

As far as I can see, this has the same issue as #643: syncing the file itself is NOT enough for durability. You have to sync the directories as well.

[jgiannuzzi]

Superseded by #676 which implements only the explicit close with error reporting.

[jgiannuzzi]

Thanks @crepererum, I had only looked at issues and not pull requests and thus hadn't seen #643. I have extracted the close bits of this PR into #676. Could you please take a look at it?