feat(hooks): expose the effective permission mode in hook payloads

I maintain the Kimi Code integration in Rocky, a macOS app that surfaces coding-agent sessions and permission prompts through Kimi's plugin hooks.

On Kimi Code CLI v0.29.0, hooks cannot determine the session's effective permission mode:

• Hook payloads do not include it. For example, PreToolUse contains hook_event_name, session_id, cwd, tool_name, tool_input, and tool_call_id.
• The injected environment only contains KIMI_CODE_HOME and KIMI_PLUGIN_ROOT.
• Kimi sets its process title to kimi-code, so -y/--auto are not visible in the observed parent-process arguments.
• default_permission_mode in config.toml is not updated when v0.29.0 is launched with -y/--auto, so it does not reliably describe the active session.

This matters because PreToolUse can deny a call but cannot approve one: an allow response only lets Kimi's permission chain continue. In manual mode, Kimi still prompts in its TUI, so an external gate cannot replace that prompt. Without the effective mode, integrations must rely on user configuration to avoid duplicate interactions.

Could Kimi include the effective mode in hook payloads, for example:

{
  "permission_mode": "manual"
}

with possible values manual, auto, or yolo?

An optional field would let existing integrations adapt their behavior to the active session. Grok exposes equivalent session-mode information for this purpose.

Related: #1326, which tracks allowing hooks to participate in approval decisions.

Start by tracing how the PreToolUse hook payload is assembled and how the CLI's -y/--auto flags and config.toml permission settings are represented. The change is complete when an optional permission_mode field reports the effective manual, auto, or yolo mode without breaking existing hook payloads.