Extension Development Host fails with EADDRINUSE in WSL when using mirrored networking in WSL 2.9, works in 2.7

Does this issue occur when all extensions are disabled?: Yes

- VS Code Version: 1.128.1
- Commit: 5264f2156cbcd7aea5fd004d29eaa10209155d66
- VS Code Insiders: Reproduces with latest Insiders
- OS Version:
- Windows 11 Insider 10.0.26200.8655
- WSL 2.9.3.0
- Rocky Linux 9

## Steps to Reproduce

1. Open a WSL workspace.
2. Create a minimal extension:

`package.json`

```json
{
"name": "empty-vscode-extension",
"displayName": "Empty VS Code Extension",
"version": "0.0.1",
"publisher": "local",
"engines": {
"vscode": "^1.128.0"
},
"activationEvents": [
"*"
],
"main": "./extension.js"
}
```

`extension.js`

```javascript
exports.activate = () => {
console.error("activated");
};

exports.deactivate = () => {};
```

3. Use the following `launch.json`:

```json
{
"version": "0.2.0",
"configurations": [
{
"name": "Run Extension",
"type": "extensionHost",
"request": "launch",
"args": [
"--extensionDevelopmentPath=${workspaceFolder}"
]
}
]
}
```

4. Press **F5** (or **Ctrl+F5**).

## Expected Result

A new Extension Development Host window opens and the extension is activated.

## Actual Result

The debug session starts, the Run button becomes disabled for a few seconds, then returns to its initial state without opening the Extension Development Host window.

The extension's `activate()` function is never called.

The **Window** log reports:

```
[Extension Host] Error: listen EADDRINUSE: address already in use 127.0.0.1:
at Server.setupListenHandle [as _listen2] (node:net:2009:16)
at listenInCluster (node:net:2066:12)
at node:net:2275:7
at process.processTicksAndRejections (node:internal/process/task_queues:90:21)
```

The port number changes on every attempt.

## Things I have already verified

- Reproduces with a completely empty extension.
- Reproduces with all user extensions disabled.
- Reproduces in both Stable and Insiders.
- `activate()` is never reached.
- `Ctrl+F5` behaves the same as `F5`.
- Deleted `~/.vscode-server` and let VS Code reinstall the WSL server.
- Deleted VS Code user settings/profiles.
- Auto Attach is disabled.
- No `NODE_OPTIONS`, `VSCODE_INSPECTOR_OPTIONS` or `ELECTRON_RUN_AS_NODE` are set.
- Reproduces with a minimal `launch.json`.

## Additional observation

On my machine, the issue only occurs when WSL is configured with mirrored networking:

```ini
[wsl2]
networkingMode=mirrored
```

If I switch WSL to NAT networking:

```ini
[wsl2]
networkingMode=nat
dnsTunneling=true
```

the Extension Development Host launches correctly.

However, colleagues using mirrored networking do **not** reproduce the issue, so mirrored networking appears to be one factor in a machine-specific interaction rather than the sole cause.

I am not saying that mirrored networking is generally broken—only that changing the networking mode consistently changes the behavior on this machine.