Fix ParallelExecutor destructor deadlock

[rootkiller6788]

The ParallelExecutor destructor never returns: it stores next_task = 1
while num_tasks = 1, so the workers' wait predicate
next_task.load() < num_tasks (i.e. 1 < 1) stays false and the worker
threads are never woken to observe the terminate flag. Every construction
of ParallelExecutor (e.g. cbrunsli/dbrunsli built with
BRUNSLI_EXPERIMENTAL_GROUPS) therefore hangs forever at destruction.

Fix: store 0 instead, so 0 < num_tasks is true, workers wake up,
increment busy_count, observe terminate, and exit, letting the
destructor's finish_latch.wait complete.

Verified with a standalone reproduction of the executor (4 threads, one
execute round): before the change it timed out at destruction; after the
change it exits cleanly.

[eustas]

Hi, why it is draft? Do you plan to refine that?

[rootkiller6788]

Hi eustas, thanks for checking in - sorry, it sat as a draft for longer than it should have. I opened it as a draft while I reproduced the deadlock locally and double-checked the change against the worker loop; that's done now, and the PR is marked ready for review.

A quick recap of the change in case it helps: in ParallelExecutor::~ParallelExecutor() the destructor set terminate = true and then stored next_task = 1 while leaving num_tasks = 1. Workers wait on next_task.load() < num_tasks, and 1 < 1 is never true, so they never woke up to observe terminate, and the destructor's finish_latch.wait(...) blocked forever. Storing next_task = 0 makes the predicate 0 < 1 true, so each worker wakes, increments busy_count, sees terminate, notifies finish_latch, and exits cleanly.

I verified it with a standalone 4-thread reproduction: destruction hung before the change and completes normally after. All the CI checks for the PR are green. Could you please take another look when you have a chance?