1680: Order by Cluster Size in 2d network view

[glstott]

Suggested title

Add cluster-size ordering to the 2D network view, addressing GI #1680

PR description

Summary

Adds a layout selector under 2D Network Settings → Network → Display with two options:

• Force directed — retains the existing default behavior.
• Order clusters by size — groups connected components by size and arranges them horizontally from smallest to largest.

The new layout:

• Keeps each cluster’s internal structure intact.
• Places equal-sized clusters together.
• Accounts for visible nodes, links, and collapsed aggregate counts.
• Fits the completed arrangement within the viewport.
• Saves the original force-directed positions and restores them when switching back.
• Persists the selected layout in session styling.

Testing

Added focused Cypress coverage that verifies:

• Cluster-size bands increase from left to right.
• Adjacent size bands do not overlap.
• Nodes move when size ordering is selected.
• Original positions are restored when returning to force-directed layout.

Also added a stress-test dataset containing:

• 204 disconnected clusters
• 5,675 nodes and 5,520 links
• Four clusters of every size from 1–50
• Outliers containing 75, 100, 150, and 250 nodes
• Chain, star, cycle, and binary-tree topologies

The targeted Cypress layout test passed.

Performance note

There is no application-defined cluster limit. Chromium’s theoretical ceiling is approximately 123,700 rendered components due to JavaScript argument limits, although practical performance depends heavily on total nodes and links and becomes constrained much earlier.

[dacowan404]

I think this is mostly good, but I do have just a few notes.
1.) using order by cluster size layout during timeline mode is a little wonky. The nodes are going all over the place, and within a cluster the nodes are very spread out with long edge lengths. When new nodes are added to a cluster they are adding increasingly far away from the cluster. I think the normal force directed layout just remembers node position so that nodes are at the same position during timeline playing. Using the recalculate position button can cause the clusters to look normal; however, we don't want to cause node positions to change during the timeline. This can be seen with the default dataset.
2.) Similarly, increasing the distance threshold, causing clusters to merge, can cause the cluster to be spread out. Using recalculate positions button causes the cluster to look normal again, so it's probably fine to implement a similar fix. Decreasing the distance threshold, causing the clusters to split, looks fine.

[glstott]

Both bugs now repaired.

[dacowan404]

currently merged into dev_dc_0926 branch, will merge into dev when available