Safety of `journal_mode=off`

mvSQLite does not need SQLite's journaling mechanism. Currently we emulate an in-memory journal to make applications happy, but this is a waste of memory. We need to figure out a way to disable journaling, safely.

There is `journal_mode=off`, but SQLite's documentation states:

> The OFF journaling mode disables the atomic commit and rollback capabilities of SQLite. The [ROLLBACK](https://www.sqlite.org/lang_transaction.html) command no longer works; it behaves in an undefined way.

So a questions is that... how *undefined* is ROLLBACK with `journal_mode=off`? If it just corrupts the "disk" image, it's fine. We listen on the `SQLITE_FCNTL_COMMIT_PHASETWO` fcntl callback so we know whether a transaction is really committed. However, if it also corrupts memory, that would be very bad.

Start by reviewing SQLite's documentation for journal_mode=off and the SQLITE_FCNTL_COMMIT_PHASETWO callback referenced in the issue. Determine how ROLLBACK behaves in mvSQLite, including whether it can corrupt the in-memory state or only the disk image; the work is done when journaling can be disabled safely or the risks are established.

Written by the indexing model from the issue text.