Honor ProgramConfig allowedTools for pi subagent dispatch

Problem

ProgramConfig.allowedTools does not have the same effect across harnesses.

The Anthropic harness forwards the field into initializeAgent, which adds entries such as Agent on top of BASE_ALLOWED_TOOLS. The pi harness never reads programConfig.allowedTools and always registers its read-only dispatch_agent tool. As a result, removing allowedTools: ['Agent'] from a single-skill program disables subagent dispatch on Anthropic but changes nothing on pi.

The pi child is well fenced: it is read-only, reuses the security extension and scrubbed Bash tool, and cannot recurse. This is a capability-parity and configuration-contract problem rather than a demonstrated sandbox escape.

Relevant code

• src/lib/programs/program-step.ts:281-291 - documents allowedTools and disallowedTools as per-program capability controls.
• src/lib/agent/runner/harness/anthropic/index.ts:57-79 - forwards both fields.
• src/lib/agent/agent-interface.ts:830-909 - adds Agent only when requested.
• src/lib/agent/runner/harness/pi/index.ts:365-411 - always registers dispatch_agent and only consumes disallowedTools.
• src/lib/agent/runner/harness/pi/subagent.ts - implements the fenced child session.

Suggested direction

Define the cross-harness mapping explicitly. The closest semantic match is allowedTools: ['Agent'] enabling pi's dispatch_agent; programs without that opt-in should not receive it. If pi intentionally exposes read-only dispatch globally, update the configuration contract and tests so callers do not treat allowedTools as portable.

Acceptance

• The intended Agent to dispatch_agent mapping is documented in code.
• A program without the subagent opt-in cannot dispatch a child in either harness.
• A program that opts in can dispatch under both harnesses.
• Existing pi child security controls and the depth-one limit remain intact.
• Focused tests cover both an opted-in and opted-out program.

Read the capability documentation in src/lib/programs/program-step.ts:281-291, then compare the Anthropic forwarding in src/lib/agent/runner/harness/anthropic/index.ts:57-79 with pi registration in src/lib/agent/runner/harness/pi/index.ts:365-411. Review src/lib/agent/agent-interface.ts:830-909 and pi/subagent.ts before adding focused opted-in and opted-out coverage. Done means the Agent-to-dispatch_agent mapping is documented, both harnesses honor it, and pi child security and depth-one limits remain intact.