[zahariash]

This work was produced with the help of language models.

Follow-up to #1482 for the two points in the review comment.

Timer race. With a query timeout, the waiting thread reads the statement's timer while the thread running IMPORT DATABASE restarts it for each imported statement, and the start time was a plain time_point. On main, TSan reports the race in TaskSchedulerTest.TimeoutInterruptsStatementStartedAfterDeadline (3 of 3 runs) and in an import of 1500 RETURN 1; statements on one thread with a 20 ms timeout. ActiveQuery::reset() also zeroed the timer before startTimer() set it again, so a waiter reading in between would see a long-expired deadline and interrupt the statement that was starting.

Fix. The start time is now a std::atomic, stored with release and loaded with acquire, which compile to the same plain moves as before on x86-64. A static_assert pins its size and alignment to the plain time_point, so ClientContext's layout does not change. reset() no longer zeroes the timer: a waiter reading before startTimer() now sees the previous statement's start, which has expired only if more than the timeout has passed since it. The atomic makes Timer non-copyable, so a redundant timer = Timer() in TimeMetric's constructor is gone; nothing in the tree, the extensions or the Python driver copies a Timer.

Re-check interval. Completion wakes the waiter at once, so the interval delays no wakeup. Past the deadline the waiter reads the clock every 100 ms, sees a statement that started after the deadline within 100 ms, and then sleeps until that statement's own deadline, so only timeouts under 100 ms can overrun. A scratch test that started the next statement at 13 points of the cycle measured this in a Release build: 150 and 300 ms timeouts were interrupted within 1 ms of their deadline, 20 and 50 ms ones at most 96 ms after the statement started. 1000 ms would let sub-second timeouts overrun by up to a second; 10 ms would help only timeouts under 100 ms, with ten times the wakeups. The comment on INTERRUPT_RECHECK_INTERVAL_MS now says this.

Tests. No new test: the scheduler test above reports the race under TSan on every run, so the nightly TSan job will flag it if it comes back, and a timing assertion would be flaky on loaded CI runners. With the change, TSan reports nothing in those two cases or in TaskSchedulerTest.* (3 runs each). Release ctest: 3439 passed, 0 failed; the import, export, large-copy, GDS and timeout tests also pass with MAX_NUM_THREADS=1.