Function batch_results_hash 

pub fn batch_results_hash(
    calls: &[ToolCall],
    answers: &[Option<u64>],
) -> Option<u64>

Hash the answers to one batch of tool calls.

answers[i] is the hash of the answer to calls[i], or None if that call went unanswered. Returns None when any call is unanswered, or when the two slices disagree in length: a partially-answered batch says nothing about whether work repeated, and neither does a caller that has lost track of which answer belongs to which call.

Pairs, not bare hashes. Sorting answer hashes alone would meet the ordering goal — super::batch_signature sorts too, so the same parallel batch re-emitted in a different order must still match — but it severs which call produced which result, and a two-call batch whose answers swapped between occurrences would compare equal.

The pair key canonicalises arguments through super::signature::stable_repr — the same rendering super::batch_signature uses, and that is load bearing rather than tidy. stable_repr collapses everything below MAX_REPR_DEPTH to a sentinel, so a bare Value::to_string here would distinguish batches the signature calls identical: one run, a different answers hash every occurrence, and a rescue that never ends. An observation-tier batch built that way could never be refused at all — which inverts the depth cap’s own safety argument, that a collision can only ever make the guard stricter.

It also removes a dependence the previous rendering carried on serde_json::Value being a BTreeMap: stable_repr sorts keys itself, so enabling preserve_order cannot make this join quietly under-report.