perf: optimize deep compound layout

[alixander]

Summary

• cache the stable JavaScript-ordered node enumeration and prebucket nodes by rank/compound interval
• build sparse layer graphs with exact capacities and lazy graph internals
• skip redundant ancestor-cycle walks for algorithm-generated, already-validated parent relationships
• retain exact Dagre 0.8.5 / Graphlib 2.1.8 ordering and output behavior

Why

Deep compound graphs expanded border nodes across every spanned rank, then repeatedly scanned the entire expanded graph for every layer. The inherited algorithm remains interval-sized, but the Go port was also paying avoidable repeated enumeration, allocation, key classification, and validation costs.

Impact

Apple M4, Go 1.25, one benchmark iteration per sample, three samples:

• depth 20: 50.33 ms -> 20.89 ms (2.41x)
• depth 50: 584.87 ms -> 157.08 ms (3.72x)
• depth 100: 3.599 s -> 897.18 ms (4.01x)
• depth-100 allocation bytes: 2.43 GB -> 649 MB (-73.2%)
• depth-100 allocation count: 33.1M -> 6.39M (-80.7%)

Used by d2lang/d2#2827.

Validation

• go test ./... -count=1
• go test -race ./... -count=1
• go vet ./...
• upstream Dagre 0.8.5 differential fixtures plus 100 seeded random fixtures
• git diff --check