Bridged Network TCP Bug on macOS Host

**Describe the bug**
On a macOS host, TCP connections bound to an instance's bridged network interface hang after about 50kb data are received.

**To Reproduce**
1. `multipass set local.bridged-network=en0`
2. `multipass launch -n test --bridged`
3. `multipass exec test -- curl https://canonical.com -o /dev/null --interface enp0s2`
(Sometimes need to repeat Step 3 a few times before it hangs. I don't think it's a curl bug as I've seen the same issue using netcat and even sockets directly.)

**Expected behavior**
All TCP data from the server should be received. (The curl request should complete.)

**Logs**
[bug.log](https://github.com/canonical/multipass/files/14924551/bug.log)

**Additional info**
- macOS 14.2.1

- `multipass version`
multipass 1.13.1+mac
multipassd 1.13.1+mac

- `multipass info`
Name: test
State: Running
Snapshots: 0
IPv4: 192.168.64.65
192.168.69.244
Release: Ubuntu 22.04.4 LTS
Image hash: 40ea1181447b (Ubuntu 22.04 LTS)
CPU(s): 1
Load: 0.27 0.10 0.03
Disk usage: 1.6GiB out of 4.8GiB
Memory usage: 147.7MiB out of 962.3MiB
Mounts: --

- `multipass get local.driver`
qemu

**Additional context**
The bug does not always occur. It seems more likely to occur when the incoming data arrives very rapidly. It only occurs when more than approximately 50kb are transmitted by the server.

The bug does not occur if the bridged interface is not explicitly bound to (i.e. `curl 'https://canonical.com' -o /dev/null` never hangs).

Start by reproducing the hang with the listed multipass set, launch, and curl commands on macOS, then inspect bug.log for networking clues. Trace the bridged-interface path used by the qemu driver and verify the fix by repeating the transfer with curl, netcat, or a socket; done means TCP requests on the explicitly bound interface complete without hanging.

Written by the indexing model from the issue text.