Fix parallelism cap when current thread is enrolled in concurrent HNSW merge

[abernardi597]

Closes #16729.

Description

HnswConcurrentMergeBuilder submitted all of its workers through TaskExecutor#invokeAll before any of them ran. The intra-merge executor runs a command on the calling thread when it has no spare thread, so when that happened to the first submission, the worker drained the shared batch counter before the submit loop could offer the remaining workers. Those workers then found no work left, and the merge stayed single-threaded for its whole duration even once sibling merges freed threads up.

Change

Adds TaskExecutor#invokeNoReentry, which forks as many tasks as the executor will accept and returns immediately, stopping as soon as the executor runs a command on the calling thread rather than letting that consume the caller. HnswConcurrentMergeBuilder now runs its first worker on the merge thread and offers the workers it has not placed yet again between batches, so intra-merge threads that become available mid-merge are picked up.

TaskExecutor#invokeAll is untouched, so search, faceting and the BP reorderers are unaffected. Work distribution is still the shared counter, so dynamic balance across workers is unchanged.

[CH-Abhinav]

Don't force push please.
Write commit message so that everyone can understand.