prepareStatements() prepared all nine statements over whatever handles it
already held. On an existing vectors.db, initialize() prepares them and
createTables() prepares them again, so the first nine leaked. They kept
the connection alive: close() finalized only the current handles, and
sqlite3_close_v2() left a zombie connection with 9 live statements.
LeakSanitizer on a gcc Debug ASan build reported 220 KB in 572
allocations, all indirect, from vector_submodule ("preserves vector
generation tracking while migrating update triggers"). It was found with
YAMS_TRACE_DB_LIFETIME=1, which logged close.sqlite with stmts=9.
prepareStatements() now prepares only the empty slots. A new test checks
that a second createTables() leaves the live statement count unchanged.
Signed-off-by: trvon <me@trevon.dev>
47f14f5093