Fix the batch timing model for a concurrency limit

An agent migrated a Node module from error-first callbacks to async/await. The original processBatch started every save at once. The new one awaits them one at a time in a loop, so a batch now takes the sum of the save times. Your team models how long a batch takes under a concurrency limit, to put a number on the regression and to size the fix.

An assistant wrote batch_wall_clock_ms(durations, max_concurrency), the model. It is in the editor. It has a bug. Find it and fix it.

Input and output:

• durations: how long each save takes, in ms, in the order the items arrive.
• max_concurrency: how many saves may run at the same time.
• Return how long the whole batch takes, in ms.

Rules the tests check:

• If there are no items, return 0. Treat a max_concurrency below 1 as 1.
• Model a pool of max_concurrency workers, numbered from 0, that all start at time 0.
• Hand out the items in arrival order. Each item goes to the worker that becomes free first, and on a tie, to the lowest numbered one. A worker starts its next item the moment it finishes the previous one.
• The batch ends when the last worker finishes.