feat: VPCS kernel datapath

A VPCS node's single adapter anchors on a persistent TAP the server
creates (tap create + set_owner via uBridge) and the vpcs process
attaches to by name: -e -d <gp{id8}e0p0> -n, the same
server-creates/guest-attaches shape as QEMU's netdev. -n (a vpcs fork
feature) keeps the guest's ip command from ifconfig'ing the anchor on
the host; the vpcs build is probed once per binary identity
(vpcs_tap capability, usage scan) and gates kernel links together
with ubridge_tap — anything else keeps the node on the relay (the
legacy local UDP tunnel on a stock binary, an AF_PACKET endpoint on
the anchor with a capable one).

VPCSVM takes KernelDatapathMixin: _connect_nio dispatches kernel
(enslave into the per-link bridge) / relay-on-anchor / legacy,
captures pick capture start_kernel vs the bridge engine, stop runs
under an execute lock and terminates the process before deleting the
anchor TAPs (a held device refuses deletion), and the duplicate-port
guard backstops the controller's. The NIO routes accept nio_bridge
and write suspend back on update.

_delete_anchor_taps verifies each tap is gone from sysfs and retries
a bounded three times: a holder can release its fd a moment after its
process was reaped (vpcs's daemon parent kills its console child and
exits first), so the unconditional delete raced EBUSY and leaked the
anchor intermittently.

The vpcs side needs IFNAMSIZ (16) instead of its own IFNAMESIZ (12)
for the -d name buffer — anchor names are 14 chars and truncated to a
nonexistent device, which TUNSETIFF then tries to create without
CAP_NET_ADMIN (fixed in the vpcs fork).

e2e (tests/e2e/test_vpcs_kernel_datapath.py): kernel and relay
scenarios green against the real binary — real ICMP both ways, §E.1/§
E.2 on the anchors, delay/suspend/capture, link delete/re-create,
node stop/restart self-heal, zero leftovers; the relay control passes
with both the fork binary and a stock one.

gns3server/controller/udp_link.py

@@ -221,7 +221,11 @@ class UDPLink(Link):
         be present or absent independently of the tap module. Dynamips
         Ethernet slot ports anchor on persistent TAPs the hypervisor opens
         (the tap module again — the Dynamips binary itself creates nothing),
-        so it gates like QEMU. A kernel link is an Ethernet segment, so
+        so it gates like QEMU. A VPCS node's single adapter anchors on a
+        persistent TAP the vpcs process attaches to by name (``-e -d``),
+        which needs the tap module plus a vpcs build that keeps its hands
+        off the host side of the TAP (``-n``) — its own capability on top
+        of the tap one. A kernel link is an Ethernet segment, so
         non-Ethernet ports (IOU serial, Dynamips serial/ATM/POS adapters)
         stay on the relay whatever the node's capabilities.
         """
@@ -291,6 +295,14 @@ class UDPLink(Link):
             # merely opens (nio create_tap) — the same tap-module capability
             # QEMU needs, not a Dynamips-specific one.
             return capabilities.get("ubridge_tap") is True
+        if node.node_type == "vpcs":
+            # The anchor is a uBridge-created TAP the vpcs process attaches
+            # to (-e -d): the tap module must exist, and the binary must
+            # support -n — without it every guest `ip` command would
+            # ifconfig the anchor on the host. Both strict True: an
+            # unreported one keeps the link on the relay, where it always
+            # works.
+            return capabilities.get("ubridge_tap") is True and capabilities.get("vpcs_tap") is True
         return False
 
     async def _prepare(self):