Problem
__wt_log_scan advances rd_lsn to the start of the next log file
(WT_SET_LSN(&rd_lsn, rd_lsn.l.file + 1, 0)) before it checks whether the next file's system record continues from where the previous file ended. On the "hole detected" and "no system record" breaks it exits with rd_lsn still pointing at that untouched next file. The end-of-recovery truncate then does ftruncate(WiredTigerLog.N+1, 0): the file loses its header and system record and becomes zero bytes, silently. Files between rd_lsn and the current file are already handled correctly (emptied to first_record, 256 bytes); only the boundary file is destroyed.

Fix
On both breaks, restore rd_lsn to prev_eof, the end of the last file actually scanned. Also add a default-visible notice with both offsets (this event used to be completely silent) and a diagnostic assertion that the read LSN is not at a file start before the recovery truncate.

Scope
This does not restore the records after the boundary and does not change replay: the
scan must still stop there. It fixes the invalid journal left behind and makes the event diagnosable. The inconsistent log pair can still arrive from outside WT (a file-at-a-time copy of a live dbpath, or a lost write)

Test

New csuite test test/csuite/wt18959_log_scan_truncate. It writes until the log rolls into WiredTigerLog.0000000002, kills the process without closing the connection, truncates WiredTigerLog.0000000001 to the end of its system record (256 bytes), then reopens with log=(recover=on). It asserts the boundary file is left as a valid, empty log file of 256 bytes rather than zero bytes.

Acceptance criteria

• The test fails on the unfixed tree with WiredTigerLog.0000000002 is 0 bytes after recovery and passes 5/5 with the fix (256 bytes).
• test_truncated_log still passes.
• The notice appears at default verbosity: Log scan: log 1 ends at offset 256 but log 2 continues from offset 92416, stopping recovery.