[zahariash]

This work was produced with the help of language models.

Fixes #1481.

IMPORT DATABASE and PROJECT_GRAPH run a query inside their own task and wait for it; when such tasks hold every slot, nobody can run the queued one. #1297 fixed the plain case. On a one-thread database, IMPORT DATABASE still hangs when the query has a timeout, because the import then runs on the worker, or when CALL threads is above one, because its statements then want more than one thread.

Fix. A thread that holds a slot (a worker, a caller running a task inline, or a launched thread that took over its caller's slot) registers on the queued task and runs it before waiting; idle workers can still join. With launchNewWorkerThread the new thread already works in the caller's place, so that path is unchanged and threads stay within max_num_threads. Ordinary queries pay one thread-local read per queued pipeline. No layout change: TaskScheduler's layout is extension ABI.

Timeouts. Each statement of an import restarts the timer and clears the interrupt. The worker running the import used to watch each statement's clock while another worker ran it; it now runs the statement itself. So the second commit keeps the waiting client thread watching after its first interrupt: it checks the clock again every 100 ms, and a statement that runs past the timeout is interrupted even if it started after the first deadline. A query past its deadline therefore wakes its waiting thread every 100 ms until it stops; the interval bounds how late such a statement is noticed. The two commits go in together: the first alone loses that per-statement check with two or more threads. The waiting thread reads the statement timer without synchronization while the worker restarts it; that race already exists on main with two or more threads, and both timeout tests exercise it.

Tests. ApiTest.ImportDatabaseWithOneThreadTimesOut (expects Import database failed: Interrupted.) and ImportDatabaseWithOneThreadAndThreadsSetToTwo, and TaskSchedulerTest.NestedTaskRunsOnCallerWhenNoSlotIsFree, NestedTaskWithTimeoutRunsOnWorker and NestedTaskRunsOnLaunchedThread, hang on main. LaunchedThreadStandsInForCaller fails if the caller also runs a launched thread's task, and QueuedTasksRunInParallelOnceInlineSlotsFree fails without the slot-holder check. TimeoutInterruptsStatementStartedAfterDeadline fails without the second commit. Full ctest passes; the export/import, copy_large, gds and rec_joins tests pass under MAX_NUM_THREADS=1.

[adsharma]

Two non-blocking follow-ups (from batch-4 review):

1. Timer race (timer.h:37-43 + client_context.cpp:120-127): startTime is a plain time_point — waiter reads while worker writes. Pre-existing, but the 100 ms recheck widens it to 1-thread DBs at 10 reads/s. Consider atomic/mutex or a comment documenting the benign-race assumption next to getTimeoutRemainingInMS.
2. 100 ms quantum (task_scheduler.cpp:INTERRUPT_RECHECK_INTERVAL_MS): bounds late-notice of past-deadline statements and delays any post-deadline wakeup by up to 100 ms. One-line comment on why 100 (vs 10/1000), or a latency assertion, would close it.

[zahariash]

Both are in #1556.

1. Timer's start time is now atomic, and ActiveQuery::reset() no longer zeroes it before startTimer(). On main, TSan flags the race in the re-check test and in an import of many short statements; with the change it reports nothing.
2. INTERRUPT_RECHECK_INTERVAL_MS has a comment now. Completion notifies the waiter, so the interval delays no wakeup. A statement that starts after the deadline is still interrupted at its own deadline unless its timeout is under 100 ms; then it gets at most 100 ms. 1000 ms would stretch that to a second, and 10 ms would help only those short timeouts, with ten times the wakeups.