feat: forward hook_decision_reason from PreToolUse hooks to can_use_tool callback

[Nik-Reddy]

Problem

When a PreToolUse hook returns permissionDecision: "ask" with a permissionDecisionReason, the reason string is silently dropped before reaching the SDK's can_use_tool callback. This means SDK consumers — such as Slack bots, custom approval UIs, or compliance dashboards — have no way to display why a hook is requesting human confirmation.

For example, a safety hook might flag a destructive shell command with the reason "Destructive command detected by safety hook", but downstream consumers never see this context, making the permission prompt less informative and harder to act on.

Solution

Thread the hook_decision_reason field through the permission request pipeline:

Layer	File	Change
Wire type	types.py → SDKControlPermissionRequest	Added optional hook_decision_reason field
Consumer type	types.py → ToolPermissionContext	Added hook_decision_reason: str | None with docstring
Plumbing	_internal/query.py → _handle_control_request	Reads from permission request, passes to context

The change is fully backward-compatible — hook_decision_reason defaults to None when the CLI or hook does not provide it.

Testing

Added two focused test cases:

1. test_permission_callback_receives_hook_decision_reason — Verifies the reason string is correctly forwarded when present
2. test_permission_callback_missing_hook_decision_reason — Verifies graceful default to None when the field is absent

All 462 existing tests continue to pass with no regressions.

Impact

This is a small but important change for the agent safety/governance story — it enables SDK consumers to build more informative permission UIs that surface why a tool call needs approval, not just that it does.

Fixes #816