[MayCXC]

When a step inside an IVF delete, point read or KNN query fails, an interrupt included, the statement carries on and can report success over what it has not done:

db.execute("create virtual table t using vec0(v float[4] indexed by ivf(nlist=2, nprobe=2))")
# 20 inserts
steps = 0
def interrupt_one_step():  # step 5 is inside the point query that finds the row to delete
    global steps
    steps += 1
    return steps == 5
db.set_progress_handler(interrupt_one_step, 1)
db.execute("delete from t where rowid = 5")  # succeeds
db.set_progress_handler(None, 0)
db.execute("select count(*) from t where rowid = 5").fetchone()  # (1,): the row is still there

What passes over a failed step:

• ivf_get_vector_data() reads a failed step of its rowid-map lookup as a missing row. The point query a DELETE runs to find its row then finds none, and the delete reports success with the row still in the table and the index.
• ivf_delete() reads a failed lookup the same way, and clears the slot's validity bit, decrements n_vectors and deletes the rowid-map and _ivf_vectors rows without checking any of them, so a delete can report success with the row gone from the table but still in the index.
• The KNN query stops reading centroids or cells at a failed step and ranks what it has read, returning fewer rows than it should, or none, as if they were all. With oversample, a failed read of a candidate's float32 vector keeps its quantized distance, and an unprepared statement skips the rescoring altogether.

Each of those statements and blob accesses now returns its error, and the delete or query returns it to SQLite.

Measured by interrupting one statement at each VM step on 20 rows (with the IVF define):

	runs that end wrong, main with #354	here
delete, no quantizer (untrained or trained)	32 of 123 report success: 21 with the row still in the table and the index, 11 with it in the index alone	0 of 123
delete, int8	35 of 133 report success with the row left behind	0 of 133
KNN, untrained	14 of 117 report success with no rows	0 of 117
KNN, trained, no quantizer or int8	52 of 167 report success with no rows or 11, and 8 fail with "SQL logic error"	0 of 167
KNN, int8 with oversample=4	220 of 327, the same 60 and 160 more reporting success with 20 rows or distances other than the uninterrupted query's	0 of 327

Here every interrupted KNN run reports "interrupted". A delete's failure can still read as vec0's own message, such as "could not open validity blob for chunk 1", when the interrupted step is vec0's chunk bookkeeping rather than the index's; it does on a flat column too, and in those runs the row stays in both the table and the index. And a delete interrupted at its last steps can report "interrupted" with the row already gone, from the table and the index alike, as a plain SQLite table's DELETE does under the same sweep.

Test: test_ivf_delete_interrupted_at_each_step and test_ivf_knn_interrupted_at_each_step in test-ivf.py interrupt each step of a delete and a KNN query, on an untrained and a trained index, without a quantizer and with int8, and the KNN query with an oversample of 4 too. A delete that reports success must have taken its row out of the index, and one that fails must leave the table and the index agreeing; a KNN query must report "interrupted" or return every row and distance of the uninterrupted query. All seven fail on #354's head and pass here. The Python suite passes (with -DSQLITE_VEC_EXPERIMENTAL_IVF_ENABLE=1, 315 passed, 4 skipped; without it, 239 passed, 80 skipped), and test-ivf.py passes under ASan and UBSan. The IVF build prints the same warnings as #354's head, and without the define sqlite-vec-ivf.c is not compiled. sqlite-vec-ivf.c is outside the Makefile's FORMAT_FILES, and the changed lines follow its style.

This builds on #354, and through it #351, and carries their commits: #354 makes the IVF commands, inserts and ivf_is_trained() return their errors, and left these paths because #347 and #350 change them. It merges cleanly with #347 and with #350 (on #349), and the three merged build and pass the suite (325 passed, 4 skipped) with no run of the sweep above reporting success over a failed step; #349's ivf_full_vector_read(), which quantized point reads go through, already returns its step's error. Like #354 it conflicts with #313, in the same places.

Origin. Found in the IVF port to photostructure/sqlite-vec, photostructure#12 (65817f4), whose IVF code returns these errors, and measured here after #354 named them. The sweep interrupts each step as mceachen's test_interrupt_is_reported_as_interrupt does vec0's statements in photostructure/sqlite-vec@7a9ab11, which the port extends to IVF; the change and the tests are written here for asg017's main. No open or closed PR or issue here makes the same change.