One VM running out of RAM clogged Multipass

**Describe the bug**

As per title.


**To Reproduce**
How, and what happened?
1. `multipass launch ...`
2. Do something nasty inside the VM that exhausts the RAM
3. Observe the Multipass GUI freezing, the CLI not working

**Expected behavior**
My host system should be totally unperturbed if something nasty happens inside a VM.

**Logs**

```
sep 22 17:29:27 bardor multipassd[3090]: Executing 'wall The system is going down for poweroff now'
sep 22 17:29:59 bardor multipassd[3090]: Could not broadcast shutdown message in VM: failed to obtain exit status for remote process 'wall The system is going down for poweroff now': timed out after 5000 ms
sep 22 17:29:59 bardor multipassd[3090]: Dropping cached SSH session
sep 22 17:29:59 bardor multipassd[3090]: QMP: {"timestamp": {"seconds": 1758554999, "microseconds": 768175}, "event": "POWERDOWN"}
sep 22 17:29:59 bardor multipassd[3090]: VM powering down
sep 22 17:29:59 bardor multipassd[3090]: QMP: {"return": {}}
sep 22 17:30:21 bardor multipassd[3090]: QMP: {"timestamp": {"seconds": 1758555021, "microseconds": 503089}, "event": "RTC_CHANGE", "data": {"offset": 0, "qom-path": "/machine/unattached/device[4]/rtc"}}
sep 22 17:34:59 bardor multipassd[3090]: SSH session disconnected
sep 22 17:34:59 bardor multipassd[3090]: Caching new SSH session
sep 22 17:35:04 bardor multipassd[3090]: QMP: {"timestamp": {"seconds": 1758555228, "microseconds": 504395}, "event": "RTC_CHANGE", "data": {"offset": 0, "qom-path": "/machine/unattached/device[4]/rtc"}}
sep 22 17:35:05 bardor multipassd[3090]: SSH session disconnected
sep 22 17:35:05 bardor multipassd[3090]: Caching new SSH session
sep 22 17:35:10 bardor multipassd[3090]: SSH session disconnected
sep 22 17:35:10 bardor multipassd[3090]: Caching new SSH session
sep 22 17:35:15 bardor multipassd[3090]: SSH session disconnected
sep 22 17:35:15 bardor multipassd[3090]: Caching new SSH session
sep 22 17:35:20 bardor multipassd[3090]: SSH session disconnected
sep 22 17:35:20 bardor multipassd[3090]: Caching new SSH session
sep 22 17:35:25 bardor multipassd[3090]: SSH session disconnected
sep 22 17:35:25 bardor multipassd[3090]: Caching new SSH session
sep 22 17:35:30 bardor multipassd[3090]: SSH session disconnected
sep 22 17:35:30 bardor multipassd[3090]: Caching new SSH session
sep 22 17:35:36 bardor multipassd[3090]: SSH session disconnected
sep 22 17:35:36 bardor multipassd[3090]: Caching new SSH session
sep 22 17:35:41 bardor multipassd[3090]: fetch manifest periodically
sep 22 17:35:41 bardor multipassd[3090]: SSH session disconnected
sep 22 17:35:41 bardor multipassd[3090]: Caching new SSH session
...
sep 22 17:37:13 bardor multipassd[3090]: SSH session disconnected
sep 22 17:37:13 bardor multipassd[3090]: Caching new SSH session
sep 22 17:41:20 bardor multipassd[3090]: QMP: {"timestamp": {"seconds": 1758555680, "microseconds": 509188}, "event": "RTC_CHANGE", "data": {"offset": 0, "qom-path": "/machine/unattached/device[4]/rtc"}}
sep 22 17:44:47 bardor multipassd[3090]: QMP: {"timestamp": {"seconds": 1758555887, "microseconds": 535864}, "event": "RTC_CHANGE", "data": {"offset": 0, "qom-path": "/machine/unattached/device[4]/rtc"}}
sep 22 17:50:45 bardor multipassd[3090]: fetch manifest periodically
sep 22 17:50:59 bardor multipassd[3090]: SSH session disconnected: [ssh proc] failed to open session channel: 'Socket error: Connection reset by peer'
```

**Additional info**
- OS: Ubuntu 25.04
- CPU architecture or model: amd64
- `multipass version`

```
multipass 1.17.0-dev.456+gcb628d61
multipassd 1.17.0-dev.456+gcb628d61
```

- `multipass info`

```
multipass info
Name: rock-dev
State: Stopped
Snapshots: 0
IPv4: --
Release: --
Image hash: 834af9cd766d (Ubuntu 24.04 LTS)
CPU(s): --
Load: --
Disk usage: --
Memory usage: --
Mounts: --
```

- `multipass get local.driver` `qemu`

**Additional context**
Add any other context about the problem here.

Start by reproducing the failure with `multipass launch ...` using the QEMU driver and an instance that exhausts its RAM. Inspect how `multipassd`, the GUI, and CLI behave during the incident; done means the host, GUI, and CLI remain responsive when the VM runs out of memory.

Written by the indexing model from the issue text.