docker-desktop distro crash-loops with `Operation canceled @p9io.cpp:258 (AcceptAsync)`; Docker engine never starts (Win10 22H2, kernel 6.18.33.2-2)

## Summary

Docker Desktop becomes permanently unresponsive because its WSL2 distro (`docker-desktop`) enters a crash cycle driven by a 9P/`p9io` failure. The utility VM stays up and the distro is restarted repeatedly, but each attempt dies before `dockerd` starts, so the Windows-side backend waits forever for the engine.

This appears to be the same failure mode as #41484 (closed as stale) and #41191 (open), observed on Windows 10 22H2.

## Environment

| Item | Value |
|---|---|
| Windows | 10.0.19045.6456 (Windows 10 22H2) |
| WSL | 2.7.14.0 |
| Kernel | 6.18.33.2-2-microsoft-standard-WSL2 |
| WSLg | 1.0.73.2 |
| MSRDC | 1.2.7214 |
| Docker Desktop | 4.71.0 (225177) |
| Docker Engine | 29.4.1 |
| Distro | `docker-desktop` (Docker-managed), plus `Ubuntu` |

`.wslconfig` (no custom kernel):

```ini
[wsl2]
# networkingMode=mirrored
defaultVhdSize=53687091200
[experimental]
sparseVhd=true
```

`docker-desktop` `/etc/wsl.conf`:

```ini
[automount]
root = /mnt/host
options = "metadata"
[interop]
enabled = true
```

## Symptom

`docker version` / `docker info` hang indefinitely. Docker Desktop UI stays on "Starting the Docker Engine". Killing and restarting Docker Desktop does not help; only rebooting the machine (or a full `wsl --shutdown`) clears it.

On the Windows side, the backend logs this, indefinitely:

```
[main.enginedependencies] still waiting for init control API to respond after 6h7m20.3767988s
[main.socketforward][vpnkit-bridge] /run/guest-services/socketforwarder-receive-fds.sock: does not exist yet, waiting for it to be created
[main.ipc][W] C<-S ConnectionClosed GET /ping (1.0004352s): Get "http://ipc/ping": context deadline exceeded
```

`wsl -d docker-desktop` is responsive (`uname`, `free` return instantly, load ~0.04), and `/run/guest-services/` is empty — `dockerd` and `containerd` never start.

## Evidence: kernel crash cycle

`dmesg` inside `docker-desktop` over one boot window. Each crash occurs roughly 25 s after the data disk (`sde`) is mounted:

```
[ 39.443015] EXT4-fs (sde): mounted filesystem 79d0ef33-9c4f-46ec-954e-b78362282797 r/w with ordered data mode.
[ 66.182557] Exception:
[ 66.182565] Operation canceled @p9io.cpp:258 (AcceptAsync)
[ 69.435343] systemd-journald[47]: Received SIGTERM from PID 1 (systemd-shutdow).
[ 69.777246] EXT4-fs (sde): unmounting filesystem 79d0ef33-9c4f-46ec-954e-b78362282797.
[ 601.029473] mini_init (121): drop_caches: 1

[ 1015.322100] EXT4-fs (sde): mounted filesystem 79d0ef33-9c4f-46ec-954e-b78362282797 r/w with ordered data mode.
[ 1036.253162] Exception:
[ 1036.253169] Operation canceled @p9io.cpp:258 (AcceptAsync)
[ 1039.498714] systemd-journald[44]: Received SIGTERM from PID 1 (systemd-shutdow).
[ 1039.770715] EXT4-fs (sde): unmounting filesystem 79d0ef33-9c4f-46ec-954e-b78362282797.
[ 1081.021581] mini_init (121): drop_caches: 1

[ 1255.654486] EXT4-fs (sde): mounted filesystem 79d0ef33-9c4f-46ec-954e-b78362282797 r/w with ordered data mode.
[ 1277.397923] Exception:
[ 1277.397928] Operation canceled @p9io.cpp:258 (AcceptAsync)
[ 1280.670938] systemd-journald[44]: Received SIGTERM from PID 1 (systemd-shutdow).
[ 1280.988326] EXT4-fs (sde): unmounting filesystem 79d0ef33-9c4f-46ec-954e-b78362282797.
[ 1321.024108] mini_init (121): drop_caches: 1
```

Alongside this, the journal is repeatedly marked unclean:

```
systemd-journald[47]: File /var/log/journal/997271786bac45bba80c636b9147e856/system.journal corrupted or uncleanly shut down, renaming and replacing.
```

And GPU-related ioctls fail continuously (also seen in #11293):

```
misc dxg: dxgk: dxgkio_query_adapter_info: Ioctl failed: -2
misc dxg: dxgk: dxgkio_is_feature_enabled: Ioctl failed: -22
```

## Host-side drvfs mounts

In the affected state, `docker-desktop` holds **28** 9p/drvfs mounts (4 host drives x several mount namespaces, plus bind-mount entries):

```
C:\ on /mnt/host/c type 9p (rw,noatime,aname=drvfs;path=C:\;uid=0;gid=0;metadata;symlinkroot=/mnt/host/,cache=0x5,access=client,msize=65536,trans=fd,rfd=5,wfd=5)
D:\ on /mnt/host/d type 9p (...)
... (repeated under /tmp/docker-desktop-root/... and per-bind-mount)
```

This is relevant because the controlled experiment in #41484 narrowed the trigger to drvfs automount.

## Relation to existing issues

- **#41484** (`p9io.cpp:258 (AcceptAsync) + docker veth teardown + journal corruption`): identical `Operation canceled @p9io.cpp:258 (AcceptAsync)` signature on Windows 10 22H2 / WSL 2.7.12 / kernel 6.18.33.2-2 / WSLg 1.0.73.2. Closed by the stale bot, not by a fix. A controlled experiment there showed that disabling drvfs automount (`/etc/wsl.conf` → `[automount] enabled=false`) eliminated the crash entirely.
- **#41191** (`Kernel BUG at fs/namei.c:844 (try_to_unlazy) after 9P/virtiofs channel disruption`): open, still receiving reports on WSL 2.7.14.0 / kernel 6.18.33.2-2.
- **#11293**: same `dxgkio_query_adapter_info` ioctl failures.

## What does not work / what works

- **Restarting Docker Desktop alone**: does not help. The backend reconnects to the same broken distro instance.
- **`wsl --shutdown` alone**: does not help. Tried on this machine before the failure was diagnosed - the distro comes back in the same broken state. This matches docker/for-win#14804, where Docker's watchdog restarts the distro immediately, so the broken state survives.
- **Killing Docker user processes first, then `wsl --shutdown`, then starting Docker Desktop**: recovers, because the first step stops the watchdog from racing the shutdown. This is what worked here.

## Notes

- The distro's data disk lives on `D:\DockerDesktopWSL` (via Docker's `CustomWslDistroDir`), not on the system drive.
- `docker_data.vhdx` is 148 GB; D: had ~102 GB free when inspected shortly after the failure, so disk exhaustion is not the cause.
- No `.dmp` crash dump was produced.

/cc @renegadeV (from #41484), @warlockhouseefs (from #41191)

Start by comparing the dmesg crash cycle with the controlled experiment in #41484, especially the /etc/wsl.conf drvfs automount setting. Reproduce with the listed Windows 10, WSL, and kernel versions, using wsl -d docker-desktop and wsl --shutdown to inspect recovery. Done means identifying the 9P/9pio failure cause and preventing docker-desktop from crash-looping before dockerd starts.

Written by the indexing model from the issue text.