Add tool payload firewall guardrail

[RitwijParmar]

Summary

Adds a concrete first-pass implementation for the agent tool-argument policy idea discussed in #1654:

• new tool-payload-firewall guardrail plugin for OpenAI-compatible tool_calls
• flattens tool-call JSON arguments and applies exact/wildcard blocked-path rules
• adds local controls for allowed tool names, max string length, and max array size
• returns audit-ready hook_results findings that can be used in eval/replay pipelines
• adds cookbook documentation showing an agent tool-payload policy config

This is intentionally a lightweight local baseline rather than a full OPA/Rego runtime. My goal is to make the policy surface testable inside Portkey first, then leave room to evolve the same hook into Rego-backed validation if maintainers want that direction.

Why

Agent systems often cross the model boundary through tool calls: CRM writes, refunds, email sends, DB updates, and internal admin APIs. Prompt/response guardrails help, but they do not give teams a deterministic structural check over the tool-call arguments that an agent is about to execute.

This gives Portkey a gateway-native place to express policies like:

• block customer.ssn or *.api_key anywhere inside tool arguments
• cap bulk-update arrays before runaway write operations
• constrain which tools a route is allowed to call
• record exactly which path failed for replay/eval/audit

Verification

• npx jest plugins/tool-payload-firewall/scan.test.ts --runInBand
• npx tsc --noEmit --pretty false --skipLibCheck plugins/tool-payload-firewall/scan.ts plugins/tool-payload-firewall/scan.test.ts
• pre-push hook ran npm run build && node start-test.js successfully

Note: repo-wide build currently emits existing TypeScript warnings in src/providers/bytez/api.ts and src/providers/open-ai-base/index.ts; this patch does not touch those files.

AI disclosure

I used an AI coding assistant to help draft and test this contribution. I reviewed the implementation before opening the PR.

Refs #1654