streams: Include the OS error when AutoFile I/O fails #36210

This came up during review of #35492 (wallet: fail dump on incomplete writes), which switches DumpWallet from std::ofstream to AutoFile so a failed write/close/fsync properly aborts the dump. While reviewing that switch, I noticed the underlying AutoFile/BufferedFile exception messages themselves don't carry the actual reason a fread()/fwrite() call failed — only a fixed string like "AutoFile::write: write failed" — the errno that would explain why the call failed is discarded. Any caller that surfaces e.what() to a log or an error message (including the dump path in #35492, once that's wired up) loses that detail.

This PR captures errno right after the failing call and folds SysErrorString() into the thrown message for:

• AutoFile::write() / write_buffer()
• AutoFile::read() (via detail_fread())
• AutoFile::ignore()
• BufferedFile::Fill()

AutoFile::seek() is intentionally left unchanged — forcing a real, portable fseek() failure (as opposed to a null handle or EOF) across this project's CI platforms isn't practical, so it has no equivalent test coverage.

Two commits: the first adds streams_tests.cpp coverage that asserts the current behavior — the OS error is discarded on a genuine (non-EOF) I/O failure — with a TODO marking the assertion that gets flipped; the second is the fix itself, flipping that same assertion to confirm the OS error is now present.

Out of scope for this PR: wiring DumpWallet in #35492 to actually surface this detail in its own error message — that PR's dump.cpp doesn't exist in its AutoFile-based form on master yet, so that wiring has to wait for whichever of the two merges first.

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--006a51241073e994b41acfe9ec718e94-->

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/36210.

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline and AI policy for information on the review process. A summary of reviews will appear here.

<!--5faf32d7da4f0f540f40219e4f7537a3-->

LLM Linter (✨ experimental)

Possible places where named args for integral literals may be used (e.g. func(x, /*named_arg=*/0) in C++, and func(x, named_arg=0) in Python):

• BufferedFile bf{f, 8, 4} in src/test/streams_tests.cpp

^{2026-09-10 03:13:58}

<!--85328a0da195eb286784d51f73fa0af9-->

🚧 At least one of the CI tasks failed. _{Task Alpine (musl): https://github.com/bitcoin/bitcoin/actions/runs/34399219812/job/102626611981} _{LLM reason (✨ experimental): CI failed because the CTest run reported streams_tests as failed (CTest exit status 8).}

<details><summary>Hints</summary>

Try to run the tests locally, according to the documentation. However, a CI failure may still happen due to a number of reasons, for example:

• Possibly due to a silent merge conflict (the changes in this pull request being incompatible with the current code in the target branch). If so, make sure to rebase on the latest commit of the target branch.

• A sanitizer issue, which can only be found by compiling with the sanitizer and running the affected test.

• An intermittent issue.

Leave a comment here, if you need help tracking down a confusing failure.

</details>

Fixing the Alpine (musl) CI failure. Root cause: the test forced a "genuine" I/O failure by opening the file in the wrong direction (write to a read-only-opened stream, etc.), which works on every platform in CI except musl. Confirmed from musl's own source (__towrite.c/__toread.c): when it detects a direction mismatch, it sets an internal error flag and returns immediately, without ever touching errno — it never reaches the actual write(2)/read(2) syscall. glibc happens to set errno in that same internal check as a courtesy, which is why this worked everywhere else; musl isn't required to and doesn't.

Fix: force a genuine kernel-level failure instead of relying on that libc-internal precheck. On POSIX, the file is now opened in the correct direction and its underlying fd is closed out from under the FILE* before the read/write attempt — since the direction is correct, musl's precheck never triggers, so the call reaches the real syscall, which the kernel fails with EBADF and sets errno for, reliably, on every libc. Windows keeps the original wrong-direction technique, since CI already confirmed that produces a genuine, errno-bearing failure there.

-<ins>Updates</ins>:

• Fixed Alpine (musl) CI failure as described above.