Fix dropped-cable bug, tag VLAN 214 on FS.com switch uplinks

Found while wiring up VLAN 214 on switch uplink ports: export_topology.py
deduped edges by DEVICE PAIR, so when a switch had two real cables to the
same neighboring device (very common here -- most FS.com field switches
run both SFP ports 9 and 10 into the same local patch panel before fanning
out from its rear side) only one of the two cables survived into the
graph. 43 real physical links across 30 device pairs were silently
missing from the diagram.

- export_topology.py: edges keyed per Cable (cable_id), never deduped by
  device pair. Edge count 80 -> 123.
- generate_drawio.py: the tree-layout DFS had a matching bug -- a node's
  neighbor list wasn't deduped before recursing, so a parallel edge to an
  already-visited node got walked a second time, found no unvisited
  children, and got counted as a phantom extra leaf. One phantom leaf per
  redundant cable was inflating page height for no reason (bogus page
  height >16000px, clipped by draw.io's render cap, before this fix).

NetBox changes (per user): all 42 FS.com IES3110-8TFP-R field switches'
SFP ports (9 and 10, whichever are actually cabled -- chain-end switches
only use port 9) are now interface.mode='tagged' with untagged_vlan=214
(Switch Management), the native VLAN on what the user confirmed are
redundant trunk uplinks. 63 interfaces updated; the diagram now shows
'9·V214' style tags on those connectors. Department-VLAN tagging (the
other half of each trunk) is intentionally not done yet -- needs a real
per-switch mapping, not a guess.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NM3nivbufxEWiKKmatEtEe

README.md

@@ -40,6 +40,14 @@ Deliberately left out: literal switch CLI config dumps -- those belong in
 the switches' NetBox config-context/notes, not pasted into a topology
 diagram where they'd immediately go stale.
 
+Current convention (documented in NetBox, not hardcoded anywhere in these
+scripts): every FS.com `IES3110-8TFP-R` field switch trunks VLAN 214
+(Switch Management) as the native/untagged VLAN on both its SFP uplink
+ports (named `9`/`10` or `Gi1/9`/`Gi1/10` depending on the device), tagged
+alongside whatever department VLAN (AMI/Gas and Water/Electric/...) that
+switch belongs to. Department-VLAN tagging isn't populated yet -- it needs
+a real per-switch/site mapping, not a guess.
+
 Connectors in the `.drawio` file are glued by shape id (draw.io's native
 `source`/`target` reference on each edge) -- drag a switch or panel in the
 app and its links follow, port-tick decorations included since they're
@@ -80,6 +88,17 @@ never drifts from what NetBox actually says.
   perfectly good cable on both sides of a port and still fail to trace if
   that mapping is missing -- check `FrontPort.objects.get(...).mappings.count()`
   before assuming the far end really is disconnected.
+- **Two devices can be joined by more than one real cable.** Most FS.com
+  field switches (`IES3110-8TFP-R`) run both SFP ports (9 and 10) as
+  redundant trunk links, often both landing on the same local patch panel
+  before fanning out from its rear ports -- so `export_topology.py` keys
+  edges by cable, never by device pair, or a second real cable between
+  the same two devices silently disappears. Layout has the same trap one
+  level up: dedupe a node's *neighbors* before recursing in the tree
+  layout, or a parallel edge gets walked twice and the second pass finds
+  its whole subtree already `visited`, so it gets recorded as a phantom
+  extra leaf -- inflates the page height for no real reason, one phantom
+  leaf per redundant cable.
 
 ## Possible next step