[coordinator] Sweep the dependency graph benchmark over the constructor pool

[liran-funaro]

BenchmarkDependencyGraph covers both managers but exercises the default one at only 2 and 4 local
dependency constructors, so it cannot say whether that pool is what bounds it — the question anyone
tuning num-of-local-dep-constructors is actually asking.

Widen the sweep to 1 / 2 / 4 / 8 / 16 / 32. The answer is that the pool is not the bound: 216,886 /
249,691 / 220,000 / 246,929 / 221,484 / 228,068 tx/s, no trend, because the ceiling is in the global
manager's two single goroutines. That is worth pinning in a benchmark, since the setting reads like a
throughput knob and is not one.

Number the batches from 1 while there, as the coordinator's own numbering does. Batch 0 does
CompareAndSwap(0-1, 0) against a counter starting at 0, which never succeeds, so it parks one
constructor goroutine permanently and loses that batch. With two or more constructors the rest carry
the load and the reported rate is unaffected — 247,439 against 249,222 tx/s — but the 1-constructor
case hangs outright, so the sweep cannot be widened without it.