Add release cached stmts command to flush DiskANN prepared statements without disconnect

[rolf-moz]

@asg017 I'm seeing some errors with Diskann because there are some prepared statements pending when we are closing the connection.

Is it advisable to have a flush command, or should I suppress these errors?

Attached is a flush implementation. As with my other patch, I heavily relied on Claude code since I don't know this codebase well.

Summary

Adds a new index-type-agnostic command dispatched via the existing FTS5-style
command column on vec0:

INSERT INTO vec_history(vec_history) VALUES('release-cached-stmts');

It calls vec0_free_resources(p) directly, finalizing the cached
sqlite3_stmt* handles vec0 keeps on the vtab (stmtRowidsInsertRowid,
stmtDiskannNodeRead, stmtVectorsInsert, etc.). They're re-prepared lazily
on the next operation.

Why

The vec0 cache is currently only finalized in xDisconnect / xDestroy /
xRename. That's a problem for some embedders. Firefox's mozStorage, for
example, calls sqlite3_close() on shutdown, which fails (and asserts in
debug builds) while any sqlite3_stmt* is still alive on the connection.
Workarounds today are either:
- a no-op ALTER TABLE rename pair — bumps the schema cookie and writes to
shadow tables, also invalidates host-side prepared-statement caches; or
- close + reopen the connection — heavy hammer.


Test plan
tests/test-release-cached-stmts.py:
- Command succeeds on a flat vec0 and data remains queryable after.
- Command is a no-op when no statements are cached yet.
- Command works on a DiskANN-indexed table (the original motivating case).
- Unknown subcommands still produce the existing unknown vec0 command error.