New 'strict' permission mode for permission-prompt tools (not yet reachable)

What

• The permission-prompt-tool flow was refactored to branch on a kind, with the existing behavior renamed "launcher" and a new "strict" path added. The kind is threaded through several internal functions, including createCanUseTool.
• Under "strict", if a permission answer changed the tool's input in a way that isn't allowed, the tool call is hard-denied instead of running.
• The sandbox's network-ask callback now takes this kind: "launcher" still applies broad, session-wide permission updates from an allowed network request, while "strict" instead applies only limited permission updates.
• The PermissionRequest hook handler now validates, for "strict" kind, that a hook's updatedInput actually matches the original input, denying the call if it doesn't rather than silently accepting the change as before.

Why

This lays the groundwork for a tighter permission mode that can't be bypassed by a hook silently rewriting tool input, though the members indicate this "strict" path isn't reachable yet.