feat(controller): offer QEMU the kernel datapath, gated per compute

Kernel eligibility becomes "both endpoints on one compute, each able to
anchor": Docker always (adapters are born as veth pairs), QEMU when that
compute's uBridge can create the persistent TAPs its adapters anchor on. The
question is asked per compute, because the link needs both ends anchored --
so a mixed or half-upgraded deployment degrades to the relay instead of
failing an attach.

probe_tap_support() creates and deletes one throwaway persistent TAP through a
scratch uBridge, cached by binary identity like the tc report; /capabilities
exposes `ubridge_tap` (absent = unknown, which keeps links on the relay).

The compute route for a QEMU adapter NIO took UDPNIO only, so a kernel link
was rejected with 422: its body and response now accept
Union[UDPNIO, BridgeNIO] exactly like Docker's.

Stale "Docker-to-Docker" wording in the config, link and MCP descriptions now
talks about anchors, and docs/features/qemu-kernel-datapath.md documents the
datapath -- verified end-to-end on a real instance: 32/32 kernel-datapath
checks and 29/29 on the relay variant.

gns3server/schemas/controller/capabilities.py

@@ -50,3 +50,8 @@ class Capabilities(BaseModel):
     ubridge_tc: Optional[UbridgeTcCapabilities] = Field(
         None, description="uBridge tc-module capabilities; absent when the probe failed or uBridge has no tc module"
     )
+    ubridge_tap: Optional[bool] = Field(
+        None,
+        description="Whether uBridge can create the persistent TAPs a QEMU adapter anchors on "
+        "(needed to wire QEMU links on the kernel datapath); absent when the probe failed",
+    )