postToolUse hook deadlocks after write-permission request, process spins at 99% CPU and ignores SIGTERM

### Describe the bug

A resumed Copilot CLI session entered a permanent deadlock after dispatching the `postToolUse` hook for an `edit` tool call that triggered a `PermissionService` write request. The process burned a full CPU core at 99% for 10 days before I noticed. It accepted no further input, produced no further log output, and ignored `SIGTERM`. Only `kill -9` terminated it.

### Affected version

`1.0.35.2` (per the debug log header: `github_copilotcli_cliversion=1.0.35.2`)

### Steps to reproduce the behavior

I cannot construct a deterministic reproduction. The deadlock happened spontaneously inside a long-running `--resume` session. The freeze coincides exactly with the dispatch of a `postToolUse` hook following a `PermissionService` write request:

1. Run `copilot --resume=` against any session
2. Use the session normally for ~2 hours
3. At some point the agent issues an `edit` tool call against a local file
4. The tool call routes through `PermissionService` (`kind=write`)
5. `postToolUse` hook dispatch begins — no further log lines are ever written
6. The process continues running at 99% CPU and ignores `SIGTERM`

### Expected behavior

- The `postToolUse` hook should complete (or fail with a logged error) and return control to the event loop.
- The process should remain responsive to `SIGTERM`.

### Additional context

**Sanitised log around the freeze point** (last 14 lines before logging stops; process kept running for 10 days after this):

```
01:16:02.773Z [DEBUG] Forwarding event for session : assistant.message
01:16:02.773Z [DEBUG] Forwarding event for session : tool.execution_start
01:16:02.773Z [DEBUG] Forwarding event for session : hook.start
01:16:02.773Z [DEBUG] Dispatching preToolUse hook for session
01:16:02.791Z [DEBUG] Forwarding event for session : hook.end
01:16:02.791Z [DEBUG] Tool calls count: 1
01:16:02.791Z [DEBUG] Running tool calls in parallel
01:16:02.791Z [DEBUG] Adding operation to queue. Current queue length: 0
01:16:02.791Z [DEBUG] Processing operation. Remaining queue length: 0
01:16:02.791Z [DEBUG] edit:
01:16:02.792Z [DEBUG] Permission request (kind=write): routing via PermissionService
01:16:02.793Z [DEBUG] Operation completed. Remaining queue length: 0
01:16:02.793Z [DEBUG] Forwarding event for session : hook.start
01:16:02.794Z [DEBUG] Dispatching postToolUse hook for session
[no further log output for 10 days while process spins at 99% CPU]
```

The `edit` tool call's `Operation completed` reaches the queue cleanup BEFORE the `postToolUse` hook is dispatched — but the `postToolUse` line is the last log entry. Looks like the hook dispatch entered a state from which control never returned.

**Coincident factor (may or may not be related):** `safari-mcp` MCP child process had been logging WebKit memory warnings in the hour leading up to the freeze:

```
00:19:35Z [ERROR] [mcp server safari-mcp stderr] WebKit memory warning: 2126MB (threshold 2100MB, limit 3000MB) — 0 MCP tabs open
00:39:35Z ... 2689MB ...
00:45:05Z ... 2195MB ...
01:03:26Z ... 2242MB ...
01:08:26Z ... 2750MB ... (8 minutes before main process freeze)
```

The 2750MB warning at 01:08:26 was 8 minutes before the freeze. Could be a stuck IPC between the main copilot process and an OOM-distressed safari-mcp child — but this is speculation; the freeze pattern in the log is consistent with a pure permission-prompt deadlock too.

**SIGTERM behaviour:** `kill ` had no effect on the deadlocked process. Only `kill -9` terminated it. The main event loop should remain responsive to `SIGTERM` even during hook dispatch.

**Environment:**
- macOS, Apple Silicon
- Node v24.11.1
- Copilot plan: enterprise
- Process accumulated ~49 hours of single-core CPU time over 10 calendar days before being killed