fix(sqlite-vec.c): report an interrupted vec0 query or write as SQLITE_INTERRUPT

vec0 replaced SQLITE_INTERRUPT from its shadow-table statements with SQLITE_ERROR and a message of its own, so callers that check for an interrupt missed it. optimize on a partitioned table also returned SQLITE_ROW when it could not look up a row's chunk, which callers saw as success.

Author: mceachen

CHANGELOG.md

@@ -35,6 +35,8 @@
 - A KNN query with a metadata filter that fails after the search has run, for example when a progress handler interrupts it between rows, now reports that error's own message, such as `interrupted`. It used to report `Could not open metadata blob`, which the filter set even when the blob opened.
 - A KNN query whose `mmr_lambda` value is not a number now fails with `mmr_lambda value in knn query must be a number between 0.0 and 1.0, provided NULL` (or `TEXT` or `BLOB`). It used to run MMR with NULL, `''`, `'abc'`, or `x'00'` read as 0.0 and with `'0.5abc'` or `x'302e35'` read as 0.5, so `mmr_lambda = ?` bound to NULL returned the rows of `mmr_lambda = 0.0`. Numeric text such as `'0.5'` or `' 0.5'` is still read as 0.5: `vec0` converts text to a number the way SQLite converts a `LIMIT` value such as `' 5'`.
 - A KNN query's `k = ?` now fails with `k value in knn query must be an integer, provided NULL` (or `TEXT`, `BLOB`, or `FLOAT`) when the value is not an integer after the conversion SQLite applies to `LIMIT ?`, which rejects such a value with `datatype mismatch`. It used to read NULL, `''`, `'abc'`, `'0.5'`, or `x'00'` as 0 and return no rows, and `5.5`, `'5abc'`, or `x'35'` as 5. `5.0`, `'5'`, and `' 5'` still mean 5. A number beyond the 64-bit integer range now gets this message too: `1e19` used to get `k value in knn query too large, provided 9223372036854775807 and the limit is 4096`, and `-1e19` used to get `k value in knn queries must be greater than or equal to 0.`
+- A `vec0` KNN query, full scan, point query, `INSERT`, `UPDATE`, `DELETE`, or `optimize` that `sqlite3_interrupt()` or a progress handler interrupts now fails with `SQLITE_INTERRUPT` and the message `interrupted`, as the same statement on an ordinary table does. When the interrupt stopped one of the statements `vec0` runs on its shadow tables, the query used to fail with a message of its own, such as `chunks iter error`, `could not open vectors blob for chunk 3`, `Could not filter metadata fields`, `Could not extract metadata value for column t at rowid 7`, or `SQL logic error`, and often with `SQLITE_ERROR`, so callers that check for `SQLITE_INTERRUPT` missed it. A point query, `UPDATE`, or `DELETE` on a rowid that is not in the table also left the message `Could not find a row with rowid 99` for SQLite to report in place of `interrupted`. Other failures of these statements keep their messages and `SQLITE_ERROR`. `CREATE VIRTUAL TABLE`, `DROP TABLE`, and `ALTER TABLE ... RENAME` still report their own messages when interrupted.
+- `optimize` on a `vec0` table with a partition key column now fails with `SQL logic error` when a row's chunk is missing from the `_chunks` shadow table. It used to return `SQLITE_ROW` from the insert that runs it, so `sqlite3_step()` returned `SQLITE_ROW`, the caller saw no error, and SQLite rolled the optimize back. An interrupt at that point now fails with `interrupted`.
 
 ### Removed