Even worse: SQLite, by default, does not immediately truncate WAL files, but rather overwrites the existing WAL from the beginning after successfully applying a checksum.
Doing what the author suggests would actually introduce data corruption errors when "restoring a WAL with a broken checksum".
However, SQLite, by default, always truncates the WAL files on last connection close
> When the last connection to a database closes, that connection does one last checkpoint and then deletes the WAL and its associated shared-memory file, to clean up the disk.
Yes, but you can't rely on an orderly database close when it comes to correctness. Non-clean shutdowns are much more common than actual low-level data corruption in many SQLite applications.
Doing what the author suggests would actually introduce data corruption errors when "restoring a WAL with a broken checksum".