SockFilter causes reproducible 15–20 second stalls in WezTerm windows/tabs and local mux IPC

### Environment

- AdGuard for Windows: **7.22.9 (5282)** / file version `7.22.5282.0`
- SockFilter driver: `adgnetworksockdrv.sys 8.0.86.0` (NFSDK `1.7.5.4`)
- Windows 11 25H2: **build 26200.8894**
- WezTerm: `20260716-195552-76b606ec`
- Shell: Windows PowerShell 5.1

### Problem

When AdGuard traffic filtering is running with the experimental SockFilter driver, every new WezTerm window or tab becomes unusable for approximately 15–20 seconds.

The GUI frame and background image are rendered, but:

- no PowerShell prompt is visible;
- keyboard input does not work;
- text cannot be selected;
- after about 15–20 seconds, the prompt appears and the terminal starts working normally.

This affects both new processes and tabs created inside an existing WezTerm window. Windows Terminal is not affected.

### Steps to reproduce

1. Enable AdGuard traffic filtering.
2. Select **SockFilter (experimental)**.
3. Wait until `adgnetworksockdrv` is installed and running.
4. Open WezTerm, or create several new tabs/windows.
5. Observe that the terminal UI is blank and unresponsive for approximately 15–20 seconds.

### Expected behavior

The shell prompt should appear immediately and the terminal should accept input.

### Actual behavior

The WezTerm window renders, but terminal I/O and input are stalled for approximately 15–20 seconds.

### A/B test

- SockFilter + active AdGuard filtering: issue reproduces.
- Stop AdGuard filtering/service: WezTerm immediately returns to normal.
- Start AdGuard again and switch to SockFilter: issue returns.
- WFP mode does not show the same behavior in the current tests.

The issue may also appear when the AdGuard UI was never manually opened because:

- `Adguard Service` is Automatic;
- `adgnetworksockdrv` is registered as `SYSTEM_START` and depends on `AFD`.

### WezTerm trace evidence

In one trace, the pane/mux was created at `11:44:08.969`, but the first PTY read occurred at `11:44:28.971`:

```text
11:44:08.969 mux/pane initialized
11:44:28.971 read_pty pane 0 read 165 bytes
```

The shell test process had already executed and written a marker file before the first PTY read, so this is not a slow PowerShell profile/startup issue.

A sampled WezTerm thread was also waiting with `WaitReason = LpcReply`.

WezTerm creates local `gui-sock-*` endpoints for GUI/mux IPC. Since SockFilter intercepts socket operations through the AFD/Winsock layer, this may be related to local socket/IPC handling, similar to issues #6084 and #6069.

### Exact driver switch timeline

```text
17:00:08.733 User confirmed enabling SockFilter
17:00:15.230 AdGuard selected a full driver restart
17:00:16.249 Began stopping adgnetworkwfpdrv
17:00:33.939 WFP driver finally stopped (about 17.67 seconds)
17:00:33.941 adgnetworkwfpdrv.sys deleted
17:00:33.942 adgnetworksockdrv 8.0.86.0 installed
17:00:33.965 SockFilter driver reported Running
17:00:34.070 Network driver and filtering rules started
17:00:34.128 Filtering reload completed; DNS cache flushed
```

After the switch, AdGuard also logged local/network handling warnings, including failures to parse `[::ffff:192.168.5.1]:53` and connection timeouts.

### Related issues

- #6084 — SockFilter blocks JetBrains Rider debug/process-list local IPC on nearly the same Windows and AdGuard versions; WFP works.
- #6069 — SockFilter causes a reproducible `LpcReply` deadlock in a Qt WebEngine application.
- #6076 — SockFilter causes severe latency over localhost/SSH local port forwarding; application exclusions do not help.

### Questions

1. Does SockFilter intercept Windows `AF_UNIX` / local Unix-domain sockets in addition to TCP/UDP sockets?
2. Is there a known approximately 15–20 second timeout in SockFilter/NFSDK when handling local IPC or AFD operations?
3. Can WezTerm or local AF_UNIX traffic be fully bypassed at the driver level?
4. What additional SockFilter debug logs, WPR profile, or kernel trace would be most useful?

Debug logs and the exact reproduction time can be provided privately.