[zahariash]

This work was produced with the help of language models.

Fixes #1397.

On a full disk, a write whose WAL append failed reported IO exception: Cannot write to file. ... Error: File too large, and the WAL was unusable after it: the next commit never returned, and closing the database aborted the process. WAL::waitForDurabilityNoLock flushed the writer before entering the try that poisons the WAL when a sync fails, so the failed flush left the WAL unpoisoned and syncInProgress set, and the next commit waited for that sync forever. The bytes stayed in BufferedFileWriter's buffer, and its destructor wrote them when the database closed: a commit the client saw fail could reach the WAL, and when that write failed too, it threw out of the destructor.

Fix.

• A failed write while appending a commit, flushing it, or flushing a checkpoint record poisons the WAL, as a failed sync does: WAL write failed; database is in a panic state and refuses further writes until restart. Poisoning also clears syncInProgress and wakes the waiting commits. A failed write of the frozen WAL's CHECKPOINT record, which already poisoned the WAL, is now reported the same way instead of as a failed sync.
• BufferedFileWriter::flush drops its bytes even when the write fails, so neither a later flush nor the destructor writes them. Its other users, the frozen WAL's writer and the shadow file's record trailer, never flush the same writer again after a failure. It also no longer zeroes the whole buffer after every write.
• As after a failed sync, recovery on the restart (with the default throwOnWalReplayFailure off) drops a torn tail and keeps every commit whose records were written in full. When one flush carries several commits and the write stops partway, an earlier one of them can be kept although its client got the error.

Tests. Five WalTest cases (test/transaction/wal_test.cpp) make the test file system's writes fail. In WALWriteFailurePoisonsWAL the error on main is a bare IO exception and the next commit would wait forever; WALAppendFailurePoisonsWAL fails a commit larger than the writer's buffer while it is appended; in FailedWALWriteIsNotWrittenOnClose closing on main writes the failed commit's 81 bytes into the WAL; CheckpointRecordWriteFailurePoisonsWAL covers the checkpoint record and FrozenCheckpointRecordWriteFailurePoisonsWAL the frozen WAL's. With #1397's script the second write now fails at once, the close finishes, and the database reopens without the failed write. Full ctest: 3191/3191.

Touches WAL::logCommittedWAL, as #1380 does; merging the two keeps both changes.