JS: Add lazy streaming SELECT/CONSTRUCT query cursors

[rybesh]

Summary

Adds lazy streaming query cursors to the JS/WASM binding so large result sets can be pulled in bounded batches instead of being materialized into an Array or serialized into one string (which can exceed V8's ~512 MB max string length):

• Store.querySolutions(query, options?) -> QuerySolutions (SELECT)
• Store.queryTriples(query, options?) -> QueryTriples (CONSTRUCT/DESCRIBE)

Each cursor exposes nextBatch(count) (an empty array signals exhaustion; count must be >= 1) and, for SELECT, a variables getter. The wasm-bindgen-generated free() releases the cursor.

This is the productionized form of the spike in #1: SELECT and CONSTRUCT, full option parity, TS typings, docs, and tests.

How it works

The iterators are 'static because on_store() snapshots storage rather than borrowing &Store, so a cursor lives in a wasm-bindgen struct across JS calls and is MVCC-isolated — an open cursor keeps yielding the rows that matched at query time even if the store is concurrently mutated. The snapshot is pinned until free().

Option parsing is shared with query() via a new execute_query() helper, so the cursors get full parity (base_iri, default_graph, named_graphs, use_default_graph_as_union) with no behavior change to query().

Why

Downstream dkglab/graph-store#50 / british-music-trade/spaestiem#103: the worker serializes a SELECT into one string and hits the V8 cap on large datasets (silent empty table on a 200 MB fixture). The binding-level primitive both downstream consumer shapes need (random-access window + one-pass stream) is exactly this batched pull.

Testing

Red→green TDD. js/test/store.test.ts adds #querySolutions() (14) and #queryTriples() (8) tests covering bounded batching, stable exhaustion, full option parity vs query(), term/quad fidelity, non-matching-form rejection, MVCC snapshot isolation across a mid-iteration DELETE, and free(). Full suite: 65 passed (2 files); cargo clippy and biome clean.

🤖 Generated with Claude Code