Function batch 

pub(crate) fn batch(
    api: &str,
    key_file: &str,
    channel: &str,
    source: &str,
    auth: AuthOptions<'_>,
) -> !

Signs every op in source on one channel and submits them as one batch (D17).

The node has told agents since D26 that /api/submit-batch is the primary path for their workloads — one durability barrier per batch against one per operation — and until now the CLI could not reach it. An agent taking that advice had to hand-roll ed25519 signing and curl, which is the thing this binary exists to prevent.

The log scope is read once, not once per op. submit reads it per call because it sends one op; doing that here would put an HTTP round trip in front of every operation and spend exactly what the batch endpoint saves. One read is also correct rather than merely cheaper: admission checks that the head an op names is still in the window, not that it is the current head, so ops signed against one head are admissible in sequence behind each other.

Output is one line per op, in request order, so a script can read line n for op n without counting brackets — and the accepted and rejected totals go to stderr, following the rule the runner already documents: machine-facing on stdout, human-facing on stderr.