Problem

Two concurrent fetchAll() / fetchChunk() calls on a single operation could silently drop rows — the worst failure class (data loss, not an error).

The result pipeline behind every backend is a single stateful cursor. The kernel (SEA) path in particular threads shared, non-atomic prefetch state through KernelResultsProvider → ArrowResultConverter → ResultSlicer: each layer parks a pulled batch in a single look-ahead slot and mutates remainingRows / a shared recordBatchReader across await points with no guard. Two overlapping consumers interleave inside those non-atomic sections — a batch pulled off the cursor gets overwritten before it's delivered.

Reproduced on a 100k-row SELECT id FROM range(0, 100000) with two concurrent fetchAll():

(For reference, the Python connector's pyo3 binding wraps the same kernel stream in a RefCell, so its second concurrent fetch fails loud with Already borrowed rather than losing data. Node's napi binding waits on a tokio::Mutex instead, so both calls proceed — which is what fed the JS overwrite window.)

Fix

Serialize all result consumption on an operation via a per-operation fetch lock in DBSQLOperation (the shared facade — so both backends behave identically by construction):

• fetchAll holds the lock across its entire drain loop (calling non-locking *Internal primitives to avoid self-deadlock).
• fetchChunk / hasMoreRows hold it per call.

Holding the lock across the whole drain (not per chunk) is what produces true Thrift parity: the first fetchAll() drains the complete result set; a concurrent second one observes an exhausted cursor and returns []. No kernel change required.

Behavior change & Thrift safety

This is a behavior change only for the (ill-defined) pattern of concurrent consumers on one operation. The everyday single-consumer path is uncontended — the lock chain is an already-resolved promise.

Verified live on both backends:

THRIFT: a=100000, b=0   combined=100000
SEA   : a=100000, b=0   combined=100000   (was 99788 before)

• overlapped fetch concurrency test: passes on both SEA and Thrift.
• Thrift fetch-path regression suite (FetchAll, FetchChunk, HasMoreRows, Iterator, ResultSlicer, LimitExact, SchemaAndDrain): 39 passing, incl. fetchAll after a partial fetchChunk(20) returning the remaining 80 rows (confirms fetchChunk→fetchAll sequencing still works through the lock).
• SEA equivalent: 38 passing.
• SEA full concurrency suite: 18 passing.

This pull request and its description were written by Isaac.