Abort-signal checks in tool-permission requests now run before the 'never resolves' hang guard, not only inside it
In the code paths that send tool-permission requests and control requests, checking whether the operation has been aborted now happens unconditionally and first. Previously, the guard that intentionally hangs forever (by returning a promise that never resolves) when the process is already committed only ran inside a conditional block; now that hang guard runs after the abort check, rather than being nested inside it.
Reordering these checks means an abort is more reliably noticed before the code can get stuck in the intentional 'hang forever' branch, which should reduce cases where a permission or control request appears to freeze instead of properly cancelling.