fix(txnlog): erase a failed append's partial bytes instead of baking a framing break into the log

[kriszyp]

Fixes #748.

A transaction-log append that fails part-way through — a full disk, an exhausted quota, a short
write on a failing volume — left the bytes it had already written on disk, unaccounted for. The log
fd is opened O_APPEND, so the next successful append landed after those bytes: a partial entry
permanently embedded mid-file with valid entries on both sides. That is the one shape open-time
recovery deliberately refuses to repair (truncating there would discard committed, replicated
transactions), so every reader stops at the break and everything written after it becomes
unreachable — the reader-side consequence seen in HarperFast/harper#2016 and HarperFast/harper#2063.

writeBatchToFile() now reports how many bytes reached the file through a bytesLanded out-param
instead of collapsing a hard error to -1, and writeEntriesV1() erases that range before
throwing. Erasing is safe: writeEntriesV1 holds fileMutex across the whole append, size never
advanced over the bytes, and the commit throws — nothing acknowledged them. The erase reuses
eraseTail() from #723 (POSIX truncates back to size; Windows zero-fills the range to restore its
end-of-entries marker).

Three failure edges around that, each from a review round:

• The erase itself fails (ENOSPC then EIO). The file is retired rather than warned about: an
  appendBoundaryLost flag makes writeEntriesV1 return without writing, which the store already
  reads as "no progress" and answers by rotating to the next sequence. The orphaned bytes stay the
  trailing partial that recoverTail() can truncate, instead of becoming the mid-file break it
  must leave intact. The double fault degrades to a repairable torn tail. Retirement is set before
  the erase and lifted only on success, so a throw from inside the erase (the Windows path
  allocates) cannot leave the file appendable either.
• The landed extent is unreportable. Windows takes it from the file pointer rather than
  lpNumberOfBytesWritten, which WriteFile does not promise to set on failure; if that query also
  fails, the extent is reported as TRANSACTION_LOG_BYTES_LANDED_UNKNOWN and the file is retired
  rather than erased against a guess. A figure larger than the bytes handed to the OS is treated
  the same way — an over-large erase would cut into committed entries.
• A short header write. open() initialized a new file's header with three unchecked writes; a
  header that only partly landed still set size to the full header length, framing the first
  append from the wrong offset for the life of the file. It is now one checked write, and a short
  one removes the file — a size in (0, HEADER_SIZE) fails open()'s "too small" check on every
  future open, and freeing disk space would not heal it. (removeFile() splits into a
  fileMutex-acquiring wrapper and a per-platform removeFileLocked() body, since open() already
  holds the lock.)
• A throw during cleanup. batch.currentEntryIndex is rolled back before the erase and the
  warning emit, both of which allocate; a bad_alloc there must not leave the batch claiming
  entries that never reached disk.

Stacked on #723

This branches from kris/txnlog-committed-position-recovery (#723), which introduces eraseTail().
Review/merge that one first; the diff here is only this change.

Where to look

• writeEntriesV1()'s error branch — the erase range (committedSize .. committedSize + bytesLanded) has to match where the bytes actually landed on both platforms: POSIX appends at
  physical EOF (which equals size, hence a plain truncate), Windows seeks to size before writing
  (hence a zero-fill of exactly that span).
• The retirement path and its contract with TransactionLogStore::writeBatch — an unchanged size
  is the existing "no progress" signal that triggers rotation, the same mechanism a
  max-size file uses. The flag is deliberately sticky for the object's life: it can only
  over-retire, never under-retire, and a fresh process rebuilds the object with it clear after
  recovery has had its chance at the trailing partial.
• bytesLanded accounting in both writeBatchToFile() implementations.

Verification

Native GoogleTest, POSIX (pnpm test:native). Failure injection uses the existing macro-seam
pattern (ROCKSDB_JS_WRITEV, plus new ROCKSDB_JS_WRITE and ROCKSDB_JS_FTRUNCATE), defined only
in the rocksdb-js-native-tests gyp target — production builds resolve to the bare syscalls.

• FailedAppendLeavesTheLogOnAnEntryBoundary — fails on base with exactly the reported shape:
  file size 43 vs committed 37 (6 orphaned bytes), and after the next append the recovery scan
  returns MidFileCorruption with the entry count truncated at the break. Passes with the fix
  (scan Clean, both entries readable).
• UnerasableOrphanRetiresTheFile — ENOSPC + failing ftruncate: the retired file takes no further
  entries and the scan still classifies it TruncateTail.
• ShortHeaderWriteDiscardsTheFileInsteadOfBrickingIt — fails on base: the 5-byte file survives
  and the reopen throws "File is too small to be a valid transaction log file". Passes with the fix.
• UnerasableExtent/Unknown and UnerasableExtent/OverReported — both fail on base with the
  guard removed: the file is either appended past or erased against an untrustworthy range.
• AppendThatWritesNothingLeavesTheFileUntouched, plus two WriteBatchToFile tests for
  bytesLanded on a hard error and on a nothing-written error.

Full gates on macOS: pnpm test:native 120 passed (3 madvise tests skipped — Linux-only),
pnpm test 728 passed / 1 skipped, pnpm check clean.

Open concerns from the pre-push review

Carried here rather than resolved, so a reviewer does not have to rediscover them:

• Coverage stops at TransactionLogFile. Nothing exercises the retire → rotate → retry contract
  through TransactionLogStore::writeBatch; the native-test target does not link the store (it
  needs RocksDB), and inducing a real ENOSPC from the JS suite would need a filled volume. The
  store side was verified by reading it (transaction_log_store.cpp:831 rotates on unchanged size),
  not by a test.
• Windows has no fault injection. Its bytesLanded accounting and zero-fill erase are exercised
  only by fix(txnlog): recover the committed watermark from the log tail on load #723's own eraseTail coverage; there is no WriteFile seam, and I cannot build Windows
  locally — CI is the only verification for that backend. The decision logic those values feed
  (retire-vs-erase) is shared, and a test-only forcedBytesLandedForTests override drives it from
  the POSIX build.
• Pre-existing, not introduced here: writeBatch's open-retry loop is unbounded, so a
  persistently failing volume spins through sequence numbers. A short header write is a new way to
  reach that loop, but openFile() already reached it under the same ENOSPC condition. Worth its
  own issue rather than widening this one.

Verified false and dismissed along the way: removeFileLocked() closes the file handle before
unlinking (no Windows sharing violation), and bytesWritten is zero-initialized before every
WriteFile, so it could never have contained garbage — the repeated "uninitialized stack memory"
framing of the Windows finding was wrong, even though the underlying under-reporting risk was real
and is now fixed.

One unrelated commit

test(block-cache): await the second read so teardown cannot abort it fixes a pre-existing flake
that was blocking this PR's CI, not anything introduced here. test/block-cache.test.ts asserted
db.get() returns a Promise without awaiting it; when dbRunner closed the database first, the
in-flight read was aborted and the unhandled rejection failed the run with every test passing. It
took out the Deno and Node 24 macOS jobs on this branch while the same commit passed everywhere
else. Identical code is on main, and it is the only unawaited get-promise assertion in the suite.

Reviewed by codex + gemini + harper-domain across four rounds. Generated by Claude Opus 5.

_{Human-Review-Need: 4 @ 8fe614a}

[gemini-code-assist]

Code Review

This pull request addresses issues with failed appends leaving orphaned bytes on disk, which can cause framing breaks that prevent recovery. It ensures that partial writes are erased on failure, and if the erase itself fails, the file is retired from further appends. Additionally, short header writes during initialization now result in the file being discarded. Feedback was provided regarding the Windows implementation of writeBatchToFile, pointing out that lpNumberOfBytesWritten is unreliable on synchronous WriteFile failures and suggesting the use of SetFilePointer to accurately calculate the number of bytes that landed on disk.