test(e2e): relay capture and markers on both relay engines

The relay engines' observable paths had no live coverage: every
capture/start call in the suite sat on a kernel anchor (AF_PACKET
capture start_kernel) and markers were only asserted on marker
add_kernel. The two relay engines' own command shapes were unit-tested
only:
  * bridge engine  - bridge start_capture / bridge add_packet_filter ... mark
  * iol_bridge engine - iol_bridge start_capture / iol_bridge add_packet_filter ... mark

Docker relay control (bridge engine, 1 passed 33s): the capture start
REST call writes the ICMP exchange to a pcap off the relay bridge; a
mark filter attached with capture_node_id n1 signals exactly 10
marker.match events over the dedicated marker WS for 5 pings (5
requests + 5 replies, both directions), carrying node_id/link_id/tag and
the busybox frame length, writes exactly those 10 frames to the marker
pcap, and deleting the marker takes the pcap with it.

IOU relay control (iol_bridge engine, 1 passed 173s): the same two
checks on iol_bridge start_capture and the port's mark filter, driven
by the real IOS ping through the fabric socket relay.

Not duplicated in the ESW/VPCS/cloud relay controls: they issue the same
uBridge bridge commands through their own call sites, which stay covered
by unit tests; the IOL container relay goes through the same iol_bridge
engine already exercised here.

docs/features/docker-kernel-datapath.md

@@ -466,9 +466,10 @@ silence with the guests' links down), the filter matrix one type at a time
 (netem core and extensions, cls_bpf match-drop, the eBPF classifier, each
 asserted through real traffic), suspend, capture, link delete/re-create,
 container stop/start, a relay negative control — whose own filters
-(delay/frequency_drop/bpf) are asserted to really shape the relay wire as
-uBridge userspace bridge filters — and the relay→kernel upgrade on project
-reopen (the datapath choice is flipped across a server restart). The container image is digest-pinned and pulled through the
+(delay/frequency_drop/bpf) really shape the relay wire, whose capture and
+markers ride the same relay engine (`bridge start_capture`, the bridge
+`mark` filter) — and the relay→kernel upgrade on project reopen (the
+datapath choice is flipped across a server restart). The container image is digest-pinned and pulled through the
 server's own pull route on a cache miss, so collaborators test the same
 bytes.
 

docs/features/iou-kernel-datapath.md

@@ -153,7 +153,8 @@ bridge, netem delay, the TAP-anchor classifier spot check
 stop/start rewiring with a delay filter restored on the fresh anchor
 (tc and traffic both), the serial link staying on the relay, and a relay
 negative control whose real `delay`/`frequency_drop` filters ride the
-port's `iol_bridge add_packet_filter` list.
+port's `iol_bridge add_packet_filter` list — capture and markers on the
+same engine (`iol_bridge start_capture` / the port's `mark` filter).
 
 The uBridge side passed its own 30/30 (`tests/iol/test_tap_anchor.py` in the
 fork), including the DOWN-anchor resilience and kernel-bridge interop this