docs(bugs): record the NetworkManager TAP-release root cause, repro and fix

A kernel-datapath link could die silently after a delete/recreate: on
NetworkManager hosts, NM's state machine releases an NM-managed TAP from
its bridge 58-87 ms after (re)enslavement (~50% while the tap has not
been assumed yet; the port stays up, no GNS3 process logs anything).
Root-caused with a server-free minimal harness (one uBridge, one tap,
one bridge, an addif/delif loop) and a single-variable NM A/B; the
NetworkManager side is explained by three of its commits (assumption
recheck on external enslavement, master removal during activation,
external changes not touching assumed slaves).

Records: forensic signatures (ifindex unchanged, flags 0x300 cleared,
heal-on-next-update), the reproducer, the verified host fix
(unmanaged-devices conf.d snippet: 19-20/40 -> 0/40, and the e2e
scenario green with test-side workarounds disabled), scope and history
(2016 issue #440 veth incident; the 2026-10-01 ethernet-switch
incident previously misattributed). Cross-linked from the L2-anchor
spec and the switch feature doc.

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

@@ -123,6 +123,9 @@ in-place reconcile removes this particular re-enslavement, but link delete
 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.
+The full record — forensic signatures, the minimal server-free reproducer,
+the NetworkManager source-level mechanism and the verified host fix — is in
+`docs/bugs/networkmanager-tap-release.md`.
 
 ## Link-local frames (LACP, LLDP, 802.1X, STP)