test(e2e): take the switch anchors out of NetworkManager's reach

The esw kernel fast-path scenario deletes and re-creates a link, which
re-enslaves the peer anchor — and on NetworkManager hosts NM's netdev
state machine can release an NM-managed TAP from its bridge some 60-70 ms
after enslavement, ~50% of re-enslavements, while the tap is in NM's
not-yet-assumed state. The freed port stays administratively up and no
GNS3 process logs anything: the membership assert sees the join, then the
ping measures a silent blackhole (this was the line-277 e2e failure).

Root-caused with a server-free harness (one uBridge, one fresh tap, one
bridge, an addif/delif loop): the same tap frees 20/40 while NM-managed,
0/40 after `nmcli device set <tap> managed no`, 20/40 again when
re-managed. Docker's veth host ends are not NM-managed, which is why only
TAP anchors ever showed it — including the "anchor lost its bridge
membership after a ports_mapping update (TAP peers only)" incident from
the switch's development, whose conclusion is corrected in the docs.

Unmanage the anchors once the routers have booted, before the scenario
re-enslaves them; document the failure signature and the host-side remedy
(per-device nmcli call, or NM unmanaged-devices configuration) in the
L2-anchor spec and the switch feature doc.

docs/features/ethernet-switch-kernel-datapath.md

@@ -113,10 +113,16 @@ on **absorbed anchors** re-enslaving an interface owned by another node
 proved to be where links died: live testing showed an anchor occasionally
 losing its bridge membership right after a `ports_mapping` update (later
 updates then failed `delif` with EINVAL), reproducibly with qemu, IOU and
-Dynamips peers, never with Docker's veths. Replaying the exact command
-sequence by hand against uBridge (held TAPs, no server involved) did not
-reproduce it, and the in-place reconcile removes the operation entirely —
-the failure mode no longer exists by construction.
+Dynamips peers, never with Docker's veths. That failure was root-caused
+later: it is NetworkManager releasing NM-managed TAPs from their bridge
+tens of milliseconds after (re)enslavement — veths are not NM-managed,
+which is exactly why only TAP peers showed it (the mechanics and the
+`nmcli device set <tap> managed no` remedy are in the L2-anchor spec). The
+in-place reconcile removes this particular re-enslavement, but link delete
++ recreate and peer restarts still re-enslave the anchor, so the hazard
+remains on NM hosts wherever NM manages the taps; the kernel e2e scenarios
+take the anchors out of NM's hands
+(`harness.unmanage_from_networkmanager`) before they exercise those paths.
 
 ## Link-local frames (LACP, LLDP, 802.1X, STP)