perf(delegate): narrow default child toolsets

[dexhunter]

Summary

This PR addresses the child-toolset portion of #11431: delegated children should not inherit every optional toolset from the parent by default.

• When toolsets is omitted, the child receives the existing DEFAULT_TOOLSETS (terminal, file, and web), intersected with the parent's allowed surface.
• Explicit non-empty toolset requests keep the existing parent intersection and MCP-preservation behavior.
• An explicit toolsets=[] remains empty, including when the parent has MCP toolsets.
• The public delegate_task schema and removed delegation.default_toolsets config are unchanged.

Measured Result

We ran autoresearch with Weco against the actual child-agent tool schema:

• Baseline: 25,955 schema bytes, 12 tools
• Best valid result: 12,581 schema bytes, 6 tools
• Reduction: 51.5%

Public Weco run: child tool-schema autoresearch

Validation

• Strict evaluator checks default scope, explicit toolsets, empty-toolset/MCP behavior, blocked tools, public-schema stability, base revision, diff scope, and whitespace.
• 200 focused tests passed.
• uvx ruff check --fix . passed.

This is intentionally limited to the tool-surface part of #11431. It does not change child shutdown, persistence, or compaction behavior.

Refs #11431

[teknium1]

Thanks for the focused delegation reduction. The premise remains live on current main: delegate_task passes toolsets=None at tools/delegate_tool.py:2521, and _build_child_agent copies parent_enabled wholesale at tools/delegate_tool.py:1132-1133. The proposed default therefore changes the active child-construction path rather than stale code.

The implementation keeps the existing parent-surface restriction, applies the existing blocked-tool filter, preserves MCP behavior for explicit non-empty requests, and distinguishes an explicit empty list. The added tests cover the new minimal default and the empty-list/MCP edge case. Current main only changed an unrelated async completion identity block since this PR's base (47d853fdf, tools/delegate_tool.py:2844-2857); GitHub reports the PR mergeable with required checks passing.

Automated hermes-sweeper review.

[dexhunter]

Flagging something that landed after this was opened, because it changes what merging it would actually do.

#69325 (295e2035, 22 Jul) removed execute_code from DELEGATE_BLOCKED_TOOLS and dropped code_execution from _COMPOSITE_BLOCKED_TOOLSETS, deliberately, so subagents doing mechanical multi-step work don't burn iterations one tool call at a time. This PR narrows the default child surface to DEFAULT_TOOLSETS = ["terminal", "file", "web"], which doesn't include code_execution. Merged as-is, a child spawned without an explicit toolsets argument — the common path — would lose execute_code again, and the test I added (test_build_child_agent_defaults_to_minimal_toolsets) would pin that behaviour in place.

I checked this on the merged tree rather than by reading: git merge-tree against current main is still conflict-free and GitHub still reports mergeable, but the merged _build_child_agent resolves the no-explicit-toolsets branch to [t for t in DEFAULT_TOOLSETS if t in expanded_parent]. So the interaction is silent rather than a conflict, which is the part worth surfacing.

The premise the PR was written against does still hold: delegate_task still passes toolsets=None, and the fallback branches still hand the child the parent's whole enabled set. It's the default set that's now stale, not the idea.

The small fix is adding code_execution to the narrowed default so #69325 survives — that shifts the schema-size figure in the description, which I'd want to re-measure rather than guess at. Would you prefer that, or is narrowing not worth doing now that execute_code is meant to reach children? Happy to close this if the latter.