Refuse to open a session while the default connection is busy

[ShawnChen-Sirius]

main went red right after #77 with the failure that PR was meant to end, so the
stream teardown was not the cause. The full log said what the earlier ones had not:

Error: Hook timed out in 30000ms.
ChdbQueryError: chdb: a session (path=…) is active; …
Error: Worker exited unexpectedly

The hook is the suite-wide afterEach, whose first statement is
await _drainPendingOps(). It sat for the full 30s, so _closeAllSessions() never
ran, the session stayed open, and every later test in the file reported it as
active. Six failures, one cause: a native op that never settled.

Where

Only one teardown can produce that and has no gate:

new Session()
  → chdbNode.CreateConnection(key)
  → acquire_session_conn(path)
  → chdb_close_conn(g_reg.defaultConn)     // outright, mid-query

libchdb binds one data directory per process and the in-memory default holds the
slot with an empty path, so opening a session has to evict it. The whole
pendingNativeOps discipline — close()'s deferral, and #77's stream tracking —
protects session connections. Nothing protected this one, and the constructor
never consulted the registry at all.

The test that failed does exactly this race sixty times per run, and its name
claimed the race was safe.

What changes

The constructor is synchronous and cannot wait, so it refuses:

Cannot open a session while 1 standalone operation is still running on the
default connection. Await them first: opening a session closes that connection,
and closing it mid-operation aborts the engine for the whole process.

A hang thirty seconds and one test file away becomes an error at the call site
that caused it.

Counted per connection, not globally: a session-bound query in flight is no reason
to reject a second session on the same path, which is allowed. Only the three
standalone entry points mark the default connection busy. The decrement is
registered before any caller's handler, so code that awaits its own query sees
zero on the next line instead of racing the bookkeeping.

The test never exercised what it claimed

HEAVY(60_000_000) is count() FROM numbers(6e7), which the engine answers from
the range without scanning — 5ms, against sleeps of 0-3ms. The query had
usually finished before the session was opened, so most runs never entered the
race, which is why a genuinely broken invariant looked intermittent.

It now uses a query that forces per-row work (~120ms), asserts the refusal
happened rather than tolerating either outcome, and checks that the query is
unaffected and a session opens the moment it drains.

Checked

Full v3 suite before and after: the same nine failures either way (Layer 3
arrow-input and parametrized streaming, which want a different engine build than
this machine has). Nothing else in the suite opens a session while a standalone
query is outstanding. The v2 mocha half cannot run locally — mocha's yargs
dependency breaks under Node 26 — so CI is the first run of it.

🤖 Generated with Claude Code

Note

Refuse to open a Session while the default connection has in-flight operations

• new Session() now throws a ChdbConnectionError if stateless default-connection queries or inserts are still running, or if a previously closed session at a different path is still releasing its connection.
• Adds a drainPending() function that resolves once all in-flight native operations and deferred connection teardowns have settled, giving callers a clean synchronization point before opening a session.
• A module-scoped pendingDefaultOps counter tracks in-flight stateless operations; pendingTeardownPaths tracks directories with deferred teardowns after Session.close().
• Opening a session at the same path as a pending teardown is still allowed.
• Behavioral Change: code that previously opened a session concurrently with stateless queries (formerly safe) will now throw; callers must await the operation or call drainPending() first.

^{Macroscope summarized 20e7bfb.}

[ShawnChen-Sirius]

@wudidapaopao please review this PR

[wudidapaopao]

LGTM