WORKER_CONCURRENCY doesn't actually limit anything

WORKER_CONCURRENCY is the operator's only lever for controlling how much simultaneous load a single instance throws at downstream targets and how many goroutines/HTTP connections it opens at once. If it silently stops working, a burst of simultaneously-due work spawns one goroutine and one outbound HTTP request per due run, all at once, regardless of the configured limit. On a modest instance this can exhaust file descriptors, saturate the network, or hammer a downstream target hard enough to trip its rate limiting or take it down -- the exact failure mode WORKER_CONCURRENCY exists to prevent, happening silently because the config value is being read and stored correctly, just never enforced.

pkg/worker/pool.go's Pool.Run is supposed to use a buffered channel (slots) as a semaphore capping concurrent executions at cfg.Concurrency. The pattern only works if the slot is released when the goroutine finishes (inside the goroutine, after runOne returns). Here, <-slots runs immediately after launching the goroutine, in the outer loop, not after the execution completes -- a slot is freed the instant a run starts, not when it finishes, so slots <- struct{}{} essentially never blocks.

1. Configure a Pool with Concurrency: 2.
2. Feed it several (e.g. 6) simultaneously-due runs against a target that takes a noticeable, fixed amount of time to respond (e.g. a test server that sleeps 300ms per request).
3. Track how many requests the target sees concurrently (e.g. an atomic counter incremented on entry, decremented on exit, tracking the running maximum).
4. Observe: the target sees far more than 2 concurrent requests.

This is a textbook "moved code to the wrong scope during a refactor" bug: the semaphore acquire (slots <- struct{}{}) and release (<-slots) must be on either side of the work the semaphore is meant to bound. Here, the release moved from "after the protected work finishes" to "immediately after starting it," which silently turns a bounded-concurrency pattern into an unbounded one while looking, at a glance, like the same pattern.

Compare where slots <- struct{}{} (acquire) happens relative to where <-slots (release) happens, and specifically when the release actually runs relative to p.runOne completing. The defer p.wg.Done() line right next to it is a hint about where a similar "run this when the goroutine is actually finished" mechanism already exists in this function.