feat(docker): traffic-insight markers on kernel-datapath links via AF_PACKET

Markers no longer disqualify the kernel datapath. They ride the NIO like
on the relay path and attach to the veth host end through uBridge's
marker add_kernel/delete_kernel/enable_kernel commands (AF_PACKET taps,
same BPF/direction/signal semantics as the relay mark filter).

- base_node: marker anchors are now polymorphic (relay bridge name or
  kernel veth host interface); the reconcile loop is datapath-agnostic
  and DockerVM overrides the add/delete/enable primitives to translate
  the commands. Marker-name validation extracted for both add paths.
- docker_vm: kernel NIO connect/update apply markers on the veth anchor;
  link deletion tears markers down explicitly (the veth survives the
  link, unlike a relay bridge whose death drops its filters).
- controller: eligibility and start_marker no longer exclude markers or
  project-level marker definitions; the kernel NIO carries the capture
  node's marker specs.
- NIO creation accepts markers on kernel NIOs (filters still rejected).

gns3server/compute/nios/nio_bridge.py

@@ -20,10 +20,10 @@ Interface for kernel-datapath bridge NIOs.
 
 A NIO of this type instructs the node to enslave its adapter's veth host end
 into the named Linux kernel bridge instead of wiring a uBridge UDP relay.
-Frames then flow entirely in the kernel (veth -> bridge -> veth). Filters,
-markers and packet capture are not available on this datapath (they live in
-the uBridge relay); the controller must only emit this NIO type for links
-where those features are not in use.
+Frames then flow entirely in the kernel (veth -> bridge -> veth). Packet
+filters are not available on this datapath (they live in the uBridge relay);
+markers and packet capture are served by uBridge's AF_PACKET modules on the
+veth host end (marker add_kernel / capture start_kernel).
 """
 
 from .nio import NIO