vmnet-backed bridge interfaces and their default routes are not cleaned up when multipassd stops or a VM is stopped

Environment:

• multipass/multipassd 1.16.3+mac
• macOS 26.6.2 (build 25G83)
• Driver: qemu, vmnet-shared networking

Description: When an instance is running with vmnet-shared networking, multipassd/the VM's qemu process creates a bridge* interface (bridging a vmenet* member) and macOS installs a default route through it with the reject flag alongside the host's real default route(s):

default   192.168.86.1   UGScg     en1          <- real gateway
default   link#28        UCSIg   bridge100  !   <- multipass-created, reject

Stopping the specific instance (multipass stop <name>) removes its bridge/route correctly. However, fully stopping multipassd itself (sudo launchctl bootout system/com.canonical.multipassd) does not remove a second bridge (used for the general shared network) or its reject default route — it's left behind indefinitely. It only goes away after a reboot; there's no CLI command to clean it up, and killing/restarting multipassd doesn't recreate or fix it either.

While a reject route is different from a routable interface, having stale default routes accumulate in the table alongside VPN/LAN defaults is unexpected, and on a machine using several VPN/virtual interfaces at once it adds routing-table noise that's hard to attribute back to Multipass unless you know to look for it.

Steps to reproduce:

1. multipass start <instance> with vmnet-shared networking.
2. Confirm a bridge* interface + reject default route appears (netstat -rn -f inet).
3. Stop the instance, then fully unload multipassd (sudo launchctl bootout system/com.canonical.multipassd).
4. Observe the bridge interface and its reject default route are still present (ifconfig -l, netstat -rn -f inet) even though no multipass process remains running.

Expected: multipassd tears down any bridge/vmnet interfaces (and their routes) it created, either when the owning instance stops or at latest when the daemon itself shuts down.

Workaround: sudo ifconfig bridge<N> destroy manually removes it.

Additional context (possibly unrelated): This machine has both Ethernet and Wi-Fi interfaces active simultaneously, each with their own default route, plus an OpenVPN Connect client running with a split "super default route" (0/1 and 128.0/1). So the routing table already has multiple overlapping default routes before Multipass adds its own; not sure if that interacts with the cleanup behavior above or is just separately-notable complexity.

Also for what it's worth: this instance previously went through a 1.16.3+mac → 1.16.4+mac upgrade, which failed, followed by a restore-from-backup and downgrade back to 1.16.3+mac. Not sure if that upgrade/downgrade path left anything in an inconsistent state relevant to this, but flagging it in case it's a contributing factor.