docs(ubridge): the fifth L2-only creator, and the call site that used it

The spec's B table grows its fifth row: bridge add_nio_tap mints a
transient TAP when the name is free and hardens it at creation, while an
attach to an existing device (possibly a user-owned TAP with addresses)
is left untouched. The rule paragraph spells out attach-is-not-a-creation.
Delivery: uBridge fb72758, closing the gap the new e2e assertions found
(live: the switch's gns3*-0 relay TAP carried fe80::). The server issues
no link l2only of its own -- the switch call site now documents that the
TAP is minted-and-hardened by add_nio_tap, and the ESW feature doc
describes the uBridge-side close instead of a server workaround.

gns3server/compute/builtin/nodes/ethernet_switch.py

@@ -386,7 +386,10 @@ class EthernetSwitch(KernelDatapathMixin, BaseNode):
         ubridge_bridge = self._ubridge_bridge_name(port_number)
         tap = self._tap_name(port_number)
 
-        # per-port uBridge relay -- uBridge holds the TAP fd
+        # per-port uBridge relay -- uBridge holds the TAP fd. Nothing created
+        # this TAP before: add_nio_tap mints it (transient, a free name) and
+        # hardens it L2-only at creation (ubridge-l2-anchor-spec §B, the fifth
+        # creator — the server issues no link l2only of its own).
         await self._ubridge_send(f"bridge create {ubridge_bridge}")
         await self._ubridge_send(f'bridge add_nio_tap {ubridge_bridge} "{tap}"')
         # enslave the same TAP to the kernel bridge (the cloud.py::_add_linux_ethernet move)