[MayCXC]

Two commits that finish porting asg017#268 (asg017@cb147c8). This fork already has its zeroing (b632185) and its _rowid_ binding (ef903ed, from vlasky@3a64182); what it lacks is the chunk deletion. asg017 and vlasky both have it, so this PR has no twins.

Deleting the emptied chunk. A chunk whose rows are all deleted stays in _chunks, _vector_chunksNN, and _metadatachunksNN until optimize removes it:

create virtual table v using vec0(emb float[1], chunk_size=8);
insert into v(rowid, emb) values (1, '[1]'), (2, '[2]');
delete from v;
select count(*) from v_chunks;  -- 1 on main, 0 with this PR

vec0Update_Delete_DeleteChunkIfEmpty() deletes those rows once a DELETE clears the chunk's last validity bit, as cb147c8 and vlasky/sqlite-vec@3a64182 do, with three differences:

• Its failures go through vec0_error_rc(), as the rest of the delete path does, so an interrupted DELETE still fails with SQLITE_INTERRUPT. With upstream's plain SQLITE_ERROR, the new delete-emptying-chunk case of test_interrupt_is_reported_as_interrupt fails.
• It does not finalize stmtLatestChunk. That statement is SELECT max(rowid) FROM _chunks, reset after every use, so it reads the current maximum each time without being prepared again.
• It reads the bitmap with bitmap_any() and drops upstream's deleted out-parameter, which no caller reads.

Tests:

• cb147c8's chunk tests in test-insert-delete.py. All seven fail on main.
• test_legacy_insert_after_chunk_deleted now empties its chunk with DELETE alone, without the optimize call. It still fails with Error opening vector blob when ef903ed's _rowid_ binding is taken out.
• test_optimize_reclaims_pages_with_autovacuum_incremental deletes every other row instead of the upper half. Deleting the upper half now empties two chunks, which DELETE removes before optimize runs, so optimize would have nothing left to compact; with every other row deleted it still compacts four partly empty chunks into two. vlasky's port kept the upper-half delete and changed the expected count after the delete, so its optimize assertion no longer tests optimize.
• The delete-completeness fuzz target checks the shadow tables right after DELETE FROM v, as upstream's does, without the optimize call this fork added to it. Built from main, the target fails its v_chunks assertion on the first corpus input that inserts a row. A 60-second run of this branch, as the fuzz workflow does, found nothing in 10,502 inputs.
• A new delete-emptying-chunk case in test_interrupt_is_reported_as_interrupt deletes the last row of a chunk, so the interrupt test reaches the three new statements.

Zeroing tests. The first commit adds cb147c8's delete tests for int8 and bit vectors and for a text primary key, which check the zeroing b632185 does. They pass on main.

Rebased onto main at a791836. make test-loadable (466 passed, 3 skipped) and make test-unit pass, and so does the Python suite against an AddressSanitizer and UndefinedBehaviorSanitizer build. The build has no warnings. One-at-a-time deletes took as long as on main, measured on f793711: deleting every other row of a 50,000-row table took 0.25 to 0.27 s against 0.24 to 0.29 s, and deleting every row took 0.49 to 0.64 s against 0.48 to 0.65 s.

[mceachen]

Landed as 52a818d and b08c04b, thanks. Follow-up 4a8ffe0: every DELETE reopened and reread the chunk's validity blob to check whether the chunk was empty, which made DELETE 12–15% slower on a 100,000-row table. vec0Update_Delete_ClearValidity() now checks through the handle it already holds and reads the whole bitmap only once the cleared byte is zero; asg017 cb147c8 and vlasky 3a64182 reopen it the same way. Separately, f6a3244 makes the validity check test only the deleted row's own bit.