fix(docker): delete the per-link kernel bridge when a node stops

The bridge teardown only hung off the link-removal path, but deleting a
node or closing a project never issues a per-link delete — the veths
disappeared with their containers and left the bridge behind as an empty
orphan (reproduced: create a kernel link, DELETE the project, the
gns3{link_id} bridge survives). `_remove_kernel_veths` now deletes the
node's kernel-NIO bridges alongside the veth host ends: both endpoints do
it, the peer's still-enslaved port answers EBUSY (suppressed, last one
wins) exactly like link deletion, a relay NIO's uBridge bridge is left
alone (it dies with the process), and a node restart rebuilds the bridge
from the NIO in _connect_nio.

Found while cleaning up the window_drop e2e: seven such bridges had
accumulated on this host. Re-verified live: the bridge is gone after the
project delete, and the window_drop e2e (which includes a node restart
with the kernel link attached) still passes 15/15.

docs/features/docker-kernel-datapath.md

@@ -151,7 +151,13 @@ endpoints became eligible are upgraded to the kernel datapath automatically.
   attached to the host end*.
 * **Death (container stop)** — `_remove_kernel_veths` deletes the host ends
   explicitly: unlike a TAP (which died with the container netns), a veth host
-  end outlives the container. Deleting either end destroys the pair.
+  end outlives the container. Deleting either end destroys the pair. The
+  node's per-link kernel bridges go with them — deleting a node or closing a
+  project never runs the link-teardown path (no per-link delete is issued),
+  so a bridge whose ports just disappeared would stay behind as an empty
+  orphan. Both endpoints do this and the peer's still-enslaved port makes
+  the delete fail with EBUSY (suppressed, last one wins), the same contract
+  as link deletion; a node restart rebuilds the bridge from the NIO.
 
 ## Link operations