Prevent on_batch_complete from firing before all children are enqueued

[lovitt]

The bug

on_batch_complete can fire before the batch has finished enqueuing its children.

The parent enqueues children one at a time, and complete? only checks the children already registered in the batch state — it has no notion of how many there will ultimately be. On a large fan-out, an early child can finish before the parent has registered the rest; at that point, if every child the batch knows about is complete, complete? returns true and completion fires while later children are still unscheduled.

We hit this in production: a ~300-child batch fired on_batch_complete while still enqueuing, and the summary it produced was missing the results the not-yet-run children went on to write.

The fix

Mark the batch while setup is enqueuing children, and require enqueuing to be finished before a child can trigger completion:

• setup marks batch_setup_gid in_progress before scheduling and done after.
• on_child_complete returns early unless setup_complete?.
• cleanup removes the key.

Only the child-driven path is gated. A batch whose children all finish during enqueuing still completes via the parent's own complete at the end of execute, so no completion is lost. This is separate from the existing batch_completion_gid guard, which dedupes concurrent finishers on an already-enqueued batch.

Progressive batch expansion is unaffected: the marker is written during the initial setup, and an expanding child sits in the batch state as processing, so complete? stays false while it runs.

One edge case: if the root fails setup on every retry until it's marked dead, the batch has registered children but its marker never reaches done, so it never resolves. This only affects a batch whose root died before it could finish enqueuing; on master the same case instead fires on_batch_complete off the partial set, reporting a never-assembled batch as complete.

Backward compatibility

setup marks a batch in_progress while it enqueues children and done once finished; the gate only holds a batch back while it's in_progress. A batch enqueued before this change has no marker, so it's treated as fully enqueued and completes normally.

Testing

Added a spec reproducing the premature fire (written to fail on master), plus coverage for setup_complete?, the setup marker, cleanup removal, and a batch enqueued before this change (upgrade in flight).

[lovitt]

I just pushed a follow-up commit (e964835) for backwards compatibility — otherwise a batch already in flight during an upgrade would be held open and never fire on_batch_complete.