centralize approval prompts

[abhinav-oai]

Summary

• reuse GuardianApprovalRequest as the single in-core description of an approval-worthy action
• derive guardian review payloads, PermissionRequest hook payloads, and existing human-prompt transports from that one request
• keep MCP-specific prompt shaping and compatibility behavior local to MCP, while making it consume the same canonical request instead of reconstructing its own copy

Flow

Before this change, each approval producer re-described the same action several times depending on the consumer:

1. tool runtimes built hook payloads themselves
2. guardian review used its own request shape
3. session prompt APIs took parallel argument lists and rebuilt user-facing events
4. MCP had additional prompt and compatibility shaping in its own runtime path

Now each producer builds one GuardianApprovalRequest once, and the downstream paths project from it:

1. shell / unified exec / execve / apply_patch / network / MCP / request_permissions build a GuardianApprovalRequest
2. permission_request_payload() derives the hook payload when that approval kind supports hooks
3. the guardian path serializes the same request into the reviewed action
4. the user path projects the existing transport event or MCP prompt shape from that same request
5. delegated approvals reuse the canonical request instead of reconstructing a second copy in the bridge

That leaves the external protocol stable while making approval-path changes land in one core area instead of being replumbed across every producer.