d2elk: upgrade to ELK.js 0.12 through native elk-go

[alixander]

Uses elk-go v0.2.0 from d2lang/elk-go#3.

Summary

• upgrade D2's native ELK integration from the 0.8.2-compatible profile to the D2-used ELK.js 0.12 surface
• retain NODES_AND_EDGES + GREEDY_MODEL_ORDER at the root, with forced model order disabled
• use NONE + GREEDY below the root because ELK 0.12 cannot safely run the former model-order profile on compound subgraphs
• remove DisCo, which upstream no longer bundles, and refresh provider/options coverage, plugin help, and notices
• deconflict overlapping self-loop labels, including stable/ent2d2_right/elk

Compatibility

This is an intentional layout-output change, not an output-compatible runtime swap. Existing ELK diagrams can receive new node ordering and coordinates, routes, labels, and component packing. Nested children may reorder, and --elk-algorithm=disco is no longer supported.

The accepted E2E update contains 45 board-JSON, 51 SVG, and 8 text golden changes. The root-only model-order policy restores the checked-in cycle-order, dense, and extended-ascii results and removes the earlier us_map routing-quality concern.

The nested migration is required: the former nested model-order profile crashes official ELK.js 0.12 on compound graphs. No safe universal compatibility flag restores the old nested sibling order.

Validation

• 322 / 322 captured D2 graphs match the official ELK.js 0.12 worker exactly before D2 post-processing
• 110 / 110 earlier candidate E2E artifacts matched the official bundled ELK.js 0.12 integration byte-for-byte; the root-only model-order policy then reduced the accepted set to 104 artifacts
• full CI=1 GOWORK=off go test ./... -count=1 passes on Go 1.26.5
• native adapter/profile and plugin tests pass, including race and vet
• the custom-profile WASM test executes successfully under Node 24.19.0
• full non-accept E2E passes with no .got artifacts
• D2.js build passed with Bun 1.3.14 and Binaryen 131: 39 unit + 2 integration tests
• released github.com/d2lang/elk-go v0.2.0 resolves and verifies through the public module toolchain

Performance and size

No material CPU regression was established. At the dense 250-node / 1,000-edge case, the candidate used +4.56% B/op and +1.20% allocs/op. The full stripped D2 binary changed by +0.51%, and optimized WASM by +1.11%.