Deny answers from SDK hosts now settle blanked permission prompts

What

Apps that drive Claude Code through the SDK (the kit that lets other programs control it) answer permission questions by sending back a control_response. A permission question is a can_use_tool request, which asks whether a tool call, meaning one action Claude wants to take, may go ahead.

Sometimes such a request has its prompt blanked: the pending action is published with an empty request_id and the original id is kept as a suppressed_request_id. Before this release, a deny answer for it was treated as an answer to an unknown request, because the code only looked the response up by its own request_id.

Now:

• blankedPromptDenyTarget handles a deny response whose request_id equals the tool call's toolUseID.
• If a published pending action has an empty request_id and a matching suppressed_request_id, the deny settles the original blanked can_use_tool request.
• The request is then cancelled: enqueueCancelRequest is called for the response's own id.

Why

A deny sent by a host app for a blanked prompt now takes effect instead of being dropped as an unknown response, so the tool call is refused as the host intended.