fix: sort deps deterministically to prevent worst case scenario orderings

[ecPablo]

transitiveReduction() mutates s.deps in place while the inner search reads s.deps[child] for many child vertices. Which rows are already “thinned” depends on how far the outer loop has progressed. The outer loop used for m, deps := range s.deps, i.e. Go map iteration order, which is intentionally non-deterministic.

On large inputs—especially a single stdin stream built from many go mod graph runs (e.g. nested modules concatenated by gomods graph | modgraph)—runtime varied wildly. In my case the process appeared to hang or take impractically long; the same graph logic under a stable outer order completed in reasonable time.

Change

Iterate outer modules with slices.Sorted(maps.Keys(s.deps)) so processing order is deterministic and tends to reduce high-fan-out modules in a stable way, shrinking adjacency lists before later BFS work reads them.