feat: add pre-approval tool input guardrails

[seratch]

This pull request adds an opt-in pre_approval_tool_input_guardrails setting for local function tools in both regular runner execution and realtime sessions.

When enabled, function-tool input guardrails run before a pending human approval interruption is emitted. If the guardrail rejects the call, the SDK returns the guardrail message as tool output without surfacing an approval request or executing the tool. Calls that pass the pre-approval check still run the same input guardrails again immediately before execution after approval, so time-sensitive checks are revalidated on resume.

see also: openai/openai-agents-js#1358

[carltonawong]

Nice boundary to make opt-in. One invariant that may be worth adding to the tests/docs here: a human approval should authorize the same validated tool request, not just the same tool name after time has passed.

A small approval receipt shape would make that inspectable for both regular runner and realtime sessions: tool call id, tool name, input hash or canonicalized args, guardrail config/version, approval decision time, and post-approval revalidation result. Then the regression test can prove that if args or guardrail behavior change between pending approval and resume, execution fails closed or requests approval again instead of treating the older approval as current authority.