[ENHANCEMENT] Run consecutive safe read-only command tools in parallel #131

Problem (one or two sentences)

When the assistant emits several independent read-only shell commands, Zoo Code currently resolves them serially. This adds avoidable latency during codebase exploration, where commands like rg, ls, cat, git status, and git show often do not depend on each other.

Context (who is affected and when)

This affects users asking Zoo Code to inspect a codebase, gather file context, or compare several files before implementation. It is most visible when an assistant emits multiple read-only execute_command tool calls in a row.

Desired behavior (conceptual, not technical)

Zoo Code should run a bounded batch of consecutive, clearly read-only command tools in parallel once the assistant stream has completed enough to know the full batch. It should preserve tool-result ordering and keep unsafe or mutating commands on the existing serial path.

Constraints / preferences (optional)

• Only parallelize execute_command blocks that pass a conservative read-only classifier.
• Do not parallelize commands with shell control syntax, redirects, command substitution, environment assignment, or mutating flags.
• Keep approval prompts ordered even if the command executions run concurrently.
• Preserve result order in the model-visible tool results.
• Keep the batch size bounded.

Request checklist

• I've searched existing Issues and Discussions for duplicates
• This describes a specific problem with clear context and impact

Zoo Code Task Links (optional)

N/A

Acceptance criteria (optional)

• Given consecutive safe read-only execute_command tool calls, when the assistant stream is complete, then Zoo runs up to four of them concurrently.
• Given the commands complete in a different wall-clock order, then tool results are still appended in the assistant's original order.
• Given a command is unsafe, mutating, uses shell control syntax, or is not recognized as read-only, then it stays on the existing serial execution path.
• Given user approval is required, then approval prompts remain serialized.
• Existing command approval and rejection behavior remains intact.

Proposed approach (optional)

Detect batches of consecutive complete execute_command tool blocks whose commands pass a conservative read-only parser. Run each batch with Promise.all, preserve output order when pushing tool results, serialize approval prompts through an approval queue, and cap batches at four commands.

This issue and the associated PR were prepared with agentic AI assistance, then reviewed by a human. The underlying feature has been tested in production business use for several weeks in the contributor's fork.

Trade-offs / risks (optional)

The key risk is misclassifying a command as read-only. This implementation intentionally rejects shell control syntax and only allows a narrow command set plus read-only git subcommands. Maintainers may want to tune the allowlist before merging.

Related but not duplicate issues:

• [ENHANCEMENT] Reduce approval-control flash for auto-approved read-only asks #102
• [ENHANCEMENT] Tighten Task.ask sequencing for auto-approved read-only asks #105