sqlite: incremental BLOB I/O via sqlite3_blob_open()

### What is the problem this feature will solve? The public `node:sqlite` JavaScript API can only read or write a BLOB or TEXT value in full. Reading a 512 MiB value materializes 512 MiB in JavaScript, and there is no API for overwriting part of a value in place. SQLite has an API for exactly this. `sqlite3_blob_open()` and the related calls give a handle that reads and writes one value in chunks. `node:sqlite` owns the `sqlite3*` connection and does not expose it to JavaScript, so an ordinary userland implementation cannot use the existing connection. A custom loadable SQLite extension can receive that connection and call the incremental BLOB API, so this is not literally impossible outside core. It does, however, require shipping native code and designing an extension-specific bridge instead of using the public JavaScript API. ### What is the feature you are proposing to solve the problem? `database.openBlob(options)`, returning a `BlobHandle` with `byteLength`, `read()`, `write()`, `reopen()`, `close()`, and `[Symbol.dispose]`. ```js const { lastInsertRowid } = database .prepare('INSERT INTO files (name, data) VALUES (?, zeroblob(?))') .run('greeting.txt', 11); using blob = database.openBlob({ table: 'files', column: 'data', row: lastInsertRowid, }); blob.write(Buffer.from('hello'), { position: 0 }); blob.write(Buffer.from(' world'), { position: 5 }); ``` `reopen()` moves an existing handle to another row in the same column, which is how SQLite supports reusing a handle across many rows. The handle cannot resize a value. Writable handles keep SQLite's transaction open until the last one is closed, and close or disposal can therefore report a deferred commit error. Incremental writes modify raw bytes rather than executing an SQL `UPDATE`: they do not run triggers or re-check constraints, and writing TEXT can create invalid UTF-8. SQLite also disallows virtual tables, tables with generated columns, `WITHOUT ROWID` tables, and writable handles on certain i…