Two layouts beside Layout Diagram: Untangled, and Free Ports

[endrix]

On a dense workflow the edges tangle because every node's ports sit on their rows in the order the source declares them, which ELK may not change (FIXED_POS), and an input declared first whose producer is laid out last crosses every edge between. This adds two layouts to the diagram's context menu, beside Layout Diagram, Compact Layout and Serpentine Mesh Layout:

• Untangled Layout: the layered layout with ELK's hierarchical two-sided greedy switch and Brandes-Koepf placement. The ports keep the order the source declares them in.
• Free Ports Layout: the same, and each node's ports in the order a probe layout found best against crossings. The engine runs the probe with FIXED_SIDE when the graph option dialogram.portOrder is free, reads the order ELK chose per side, and puts the ports back on their own rows in that order before the real layout. By default, and after a drag, the pass does not run and the declared order stands.

Both run the boundary-flow layout with the graph's options set for the run and restored after it, so Layout Diagram itself is unchanged. The boundary-flow handler is bound to itself in the server module for that, as the reroute handler already is.

Measured on the speculation flow of chips/workflow (40 nodes, 106 edges), exported by wfpy plan --format graph as a test fixture:

layout	port order	crossings
Layout Diagram, today	declared	278
Untangled	declared	228
Free Ports	ELK's	127

The test holds the declared order under the default and the untangled options, the rows under free ports (a permutation of the same rows, every edge routed), and the three counts in that order. 325 tests pass, tsc --noEmit is clean.

Known limit of Free Ports: a reopen re-places the ports from the declaration, so a persisted Free Ports layout re-anchors its routes onto the declared rows. Persisting the chosen order would be a follow-up.