fix: make sure the delivered LAVA database opens from read-only media

[abrignoni]

Takes one piece of RLEAPP #359 and defers the rest.

What this does

lava_finalize_output() now checkpoints and returns the report database to the delete journal before closing, if it is in WAL mode.

A database whose header says journal_mode=WAL cannot be opened from read-only media: SQLite has to create a -shm file to read one, and the LAVA viewer opens the report database with OPEN_READONLY (src/main/index.js, plus workDb.js and subsetExport.js). So a report delivered on write-blocked storage, or copied without its -wal/-shm sidecars, would not open.

Demonstrated:

delivered database	header	opens read-only?
WAL, no checkpoint	wal	fails: attempt to write a readonly database
WAL, with this checkpoint	delete	opens, all 500 rows
never WAL (today)	delete	opens, all 500 rows

What this deliberately leaves out

Nothing here enables WAL. #359 also added a storage_safety.py module (~300 lines) that turns WAL on when the output path is confirmed local storage, for a large speed win on media-heavy runs. That part is not included.

The reason is timing rather than merit: lavafuncs.py is meant to stay identical across the five extractors and has already drifted (702 / 668 / 686 / 686 / 686 lines, five distinct checksums), a consolidation of the cores is planned, and adding a new ~300-line core module to one repo now would deepen that split. The WAL work is better landed once, against the unified core.

So this is a guard, not a fix for a failure happening today. With WAL never enabled by LEAPP, the branch will normally not fire. It costs three lines of runtime work at finalize and makes the guarantee explicit: whatever mode the connection ends in, the delivered .db is standalone and readable read-only.

Applied to all five cores so this one does not add drift of its own.

Original WAL work in RLEAPP #285 by @OneSixForensics; the finalize checkpoint was added during review in #359.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com

[abrignoni]

Closing. On examination this guards a state that cannot occur.

WAL is enabled in ilapfuncs.py on _Timeline/tl.db and _KML Exports/_latlong.db, never on _lava_artifacts.db, which is the only database lava_finalize_output touches. Checked against a real delivered report: _lava_artifacts.db is already journal_mode=delete with no sidecars, so the branch added here would never execute.

The reasoning error was splitting this from the WAL enablement in RLEAPP #359. The checkpoint only has value if something turns WAL on for that database; deferring the enablement left a half that does nothing. The two belong together and should land together, against the consolidated core.

For the record, the databases that are in WAL are fine as delivered: tl.db ships with a 0-byte WAL and opens from write-blocked media with all rows present, because synchronous = EXTRA is set alongside it.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com