Explore timing over the fake driver; a paused query holds back what a call in flight brings back

[TimelordUK]

The fix (v6 behaviour)

A pause that landed while a native call was in flight still let that call's events out when it returned. That meant the meta after execute or after the next result set, and an error from a fetch or nextResultSet, together with its done and free. So pause/before-execute gave meta before or after the resume, depending on timing.

The reader now parks what follows such a call (begun(), moveToNextResult, endOrPark), as it already did for fetched rows. A paused query emits nothing until it is resumed. This settles the open question in HANDOVER.md.

Not held yet: an error at execute while paused. beginQuery queues the free before it rejects, so holding the error would let free out first.

The explorer

test/contract/explore.js replays each recorded scenario many times over the fake driver. Each result is held for its recorded latency, give or take a fifth, plus a few ms. The scenario's own timers and the JS layer's steps then land at different points against the driver's results. Every run must match the corpus, with no violations. This is how the meta above was found.

• The native logs now carry timestamps, and the fake holds each result for as long as the driver took. So timer-driven scenarios (pause after 100 ms, cancel after 300 ms) replay with the server's timing.
• A timed scenario, one paused by a timer, is compared by shape and total rows, because how the rows split around the pause is down to timing.
• A failing run prints its seed, and --seed n --runs 1 replays exactly that timing.

New scenarios

These are real-server scenarios: a pause landing while the query executes (pause/during-execute-then-result, -then-error), and while a fetch is in flight (pause/during-fetch). SQL Server sends nothing of a batch until a waitfor in it is over, unless what comes before it fills a packet. That is why the first two pause during execute.

pause/before-execute, during-execute-then-result and during-fetch are agreed. during-execute-then-error stays unreviewed, because it still has no done, which is the error-path gap for #479.

Testing (Windows, localdb)

• Full suite: 992 passing.
• Replay: 84 passing, 33 s. Slower than before, because real latencies are now replayed, including the 1 s waitfors.
• Explorer: 83 of 83 scenarios held over 6 timings each, and the 3 timed pause scenarios over 8 timings at 3× jitter.

🤖 Generated with Claude Code