docs(features): quantify the kernel netem correl bias that collapses small rates

The kernel's correlated-random generator (get_crandom, sch_netem.c) truncates
instead of wrapping, starving both edges of the stationary distribution: an
event threshold below the correlation value is almost never reached. Measured
with stock iproute2 on this kernel — uBridge's netlink encoding is identical:
loss 1% + correl 25% drops nothing over 2000 pings (expected ~2%), 10%/25%
measures ~1.8% one way, only the 50% symmetry point survives. duplicate and
reorder correl share the same comparison structure and collapse the same way;
gemodel is immune (Markov chain over plain uniform draws) and is the honest
tool for bursty loss at a chosen mean rate.

Documented in the packet-filters correlation-bias bullet, and surfaced in the
two machine-facing descriptions (MCP link_update packet_loss note, controller
filter schema) so agents and clients stop walking into the trap.

gns3server/controller/link.py

@@ -54,7 +54,9 @@ FILTERS = [
         "type": "packet_loss",
         "name": "Packet loss",
         "description": "The percentage represents the chance for a packet to be lost. The optional correlation "
-        "(kernel-datapath links only) makes consecutive losses dependent, like a bursty real network",
+        "(kernel-datapath links only) makes consecutive losses dependent, like a bursty real network. "
+        "Kernel caveat: a chance at or below the correlation value collapses toward zero effective loss "
+        "(netem correlated-RNG bias) — use gemodel for bursty loss at a known mean rate",
         "parameters": [
             {"name": "Chance", "minimum": 0, "maximum": 100, "type": "int", "unit": "%"},
             {"name": "Correlation", "minimum": 0, "maximum": 100, "type": "int", "unit": "%"},