Batch Promise iterator row reads

[xoxohorses]

Description

Adds RowsIterator.nextBatch(maxRows) in Rust and updates the Promise API's existing iterate() wrapper to fetch native row batches while returning standard one-row iterator results. QueryOptions.batchSize controls the native batch size and defaults to 1, which preserves current behavior and keeps the existing all() and iterate() signatures unchanged.

This was motivated by a production trace of a simple ordered query that returned 9,088 rows: about 280 ms of its 350 ms p50 was attributed to SQLite processing. For that result size, the default all() path makes 9,088 asynchronous Rust-to-JavaScript round trips. Batching keeps SQLite's row-at-a-time stepping inside Rust and reduces those boundary crossings while the JavaScript iterator still returns one row at a time.

Benchmark

The public benchmark prepares the table before timing, reads the same rows through each configuration, and validates every result. These averages were measured on Node 22.13.1 for x64 Linux with an Intel Xeon Platinum 8375C CPU.

Rows	all() with batch size 1	all(…, { batchSize: 250 })	Speedup
1,000	13.828 ms	2.349 ms	5.89x
10,000	138 ms	22.163 ms	6.21x
100,000	1.394 s	150 ms	9.32x
1,000,000	13.954 s	1.442 s	9.68x

Benchmark source: https://github.com/xoxohorses/libsql-js/blob/cb3e8e4fa0dc14811365033f1cc4bce84e8645d8/perf/perf-libsql-batched-rows.js

How was this change tested?

• Automated test (unit, integration, etc.)
• Manual test (provide reproducible testing steps below)

Built the native module, then ran the public benchmark across 1,000, 10,000, 100,000, and 1,000,000 returned rows. The benchmark validated each result set.

[written by Codex]