Subagent dangerouslyDisableSandbox silently denied; should behave like parent

Context

With sandbox enabled (auto-approve for sandboxed Bash), a parent-agent Bash call with dangerouslyDisableSandbox: true flows through the normal permission pipeline — permission rules, auto mode, or user prompt all decide the outcome. The same call from a subagent (Agent/Task tool) is denied outright with "Permission to use Bash has been denied" — no prompt, no rule check, no chance to approve. Auto mode is off; no relevant Deny rule is set. The behavior is undocumented.

Requests

1. Subagent dangerouslyDisableSandbox should flow through the same permission pipeline as the parent. Whatever decides for the parent (allow rules, auto mode, user prompt) should decide for the subagent. Today it's silently rejected — that's the inconsistency.

1. Document subagent sandbox-escape behavior in the sub-agents and sandboxing pages of the docs. The current docs imply parity with the parent, which doesn't match observed behavior.

Why it matters

Sandbox-auto-approved sessions need a permission-policy fallback for commands that can't run sandboxed (gh, network fetches, builds outside cwd). Denying that fallback only for subagents makes them unusable for any work that crosses the sandbox boundary.

Repro

1. Enable sandbox in a session.
2. Spawn a subagent via the Agent tool.
3. Have the subagent run a Bash call with dangerouslyDisableSandbox: true (e.g. gh api ...).
4. Observe: harness denies with "Permission to use Bash has been denied", no prompt to user, even though the same call from the parent would prompt.