Create a new Leios database using the SQLite implementation.

Each call to openReader on the returned handle creates new SQLite connection; readers are not thread-safe and should not be shared across threads. All writers submit to the one write connection created here, on its own worker thread.

The registry owns the background threads (writer, copier and a thread that samples the database's size): closeLeiosDbHandle stops them in order, and closing the registry cancels whatever is still running.

Creates both files with their schemas before returning, so call it only once their directories may be non-empty (after the ChainDB marker check).

newLeiosDBSQLite with an explicit GC sweep batch size: how many EBs the writer evicts per turn, between the jobs it serves.

newLeiosDBSQLite bracketed with its closeLeiosDbHandle: on release every pending write has landed, the background threads are gone and the connections are closed, so e.g. the database files can be deleted.

Delete the EBs announced after the given slot.

For internal tooling. Works for both the volatile and the immutable partition files.

Shrink a LeiosDb file to the space its rows need.

A delete frees pages inside the file without returning them to the filesystem. This rewrites the file, so it needs free space of about the size of the file. For internal tooling.

Schema of the volatile partition (leios.vol.db): sql_schema_imm with the columns and objects that track completeness and GC.

Schema of the immutable partition (leios.imm.db): the subset of sql_schema_vol that the copier writes and the fallback reads use. The tables it keeps have the volatile columns, so the fallback reads reuse the volatile SQL verbatim and the copy is a server-side INSERT ... SELECT over ATTACH.

Left out, since EBs land here complete and are never collected: ebs.missingTxCount, ebs.status and the GC indexes.

Allocate the body's whole ebTxBytes range in one offset-ordered pass: one zeroblob row per body row, physically contiguous and fully packed. OR IGNORE: ignore duplicates (a second delivery of the same EB body).

Parameter 1: ebHashBytes

Fill one pre-allocated row in place. Guarded three ways: the row must exist (a bogus offset updates nothing), must not be filled yet (a duplicate delivery updates nothing), and the payload must have exactly the declared size (the row was allocated as zeroblob of it, and an in-place overwrite must not change the row size). One successful UPDATE is therefore exactly one previously-missing valid tx, which is what makes counting by changes() sound.

Parameters: 1 = ebHashBytes, 2 = txOffset, 3 = txBytes