Fix lost query-worker dispatch under single-flight reuse

QueryWorker.runLoop() consumed the dispatch hand-off (q = current) under
signalLock but cleared the slot (current = null) only after runOn()
returned, outside the lock. A Query lease is single-flight but reused:
the user thread loops submit() -> await() on the same handle. The
terminal callback inside runOn() wakes the user thread, which can call
submit() -> dispatch() -- setting current = q and signalling -- before
the worker thread reaches its post-run finally block. That stale
current = null then clobbered the freshly dispatched job and discarded
its already-consumed signal, so the worker parked forever on the
condition while the user thread blocked on a Completion that never
fired. The borrowed worker never returned to the pool and the caller
hung indefinitely.

Clear current under signalLock at the moment of consumption and drop the
post-run finally clear. dispatch() now cannot be clobbered: by the time
the next dispatch runs, the worker is either already awaiting (so the
signal wakes it) or will observe current != null on the while check and
skip awaiting. The exception path leaves current already null, and the
shutdown branch still clears under the lock.

Surfaced as a 60s hang in QuestDBFacadeE2ETest.testSustainedMixedConcurrency
(more threads than pool slots, repeated submit/await per lease). Was
intermittent and timing-sensitive, so it showed up mainly on aarch64 CI;
reproduced locally on x86 about one run in four, and 15/15 clean with
this fix.

Author: bluestreak01

core/src/main/java/io/questdb/client/impl/QueryWorker.java

@@ -235,15 +235,24 @@ private void runLoop() {
                     return;
                 }
                 q = current;
+                // Clear the hand-off slot under signalLock, at the moment of
+                // consumption -- NOT after runOn() returns. A lease is
+                // single-flight but reused: the user thread loops submit() ->
+                // await() on the same handle. The terminal callback inside
+                // runOn() wakes the user thread, which can call submit() ->
+                // dispatch() (current = q; signal) before this worker thread
+                // returns from runOn(). Clearing current after runOn() would
+                // race that dispatch, clobber the freshly-set job, drop its
+                // already-consumed signal, and park the worker forever while
+                // the user thread waits on a Completion that never fires.
+                current = null;
             } finally {
                 signalLock.unlock();
             }
             try {
                 q.runOn(client);
             } catch (Throwable t) {
                 q.signalUnexpected(t);
-            } finally {
-                current = null;
             }
         }
     }