Make the dual-mode example a diamond split/recombine DAG

[0-jake-0]

Summary

Reworks the dual_mode example so its graph! wiring is a diamond (split/recombine) DAG instead of a mostly-linear chain. This demonstrates that the macro's dual-mode expansion derives a non-linear graph — a shared apex node and a two-input recombine — into both the interpreted and the fully monomorphized compiled runner, and that the two agree.

           count            (apex — shared node, executed once/cycle)
          /     \
     doubled   squared      (two independent branches)
          \     /
         combined           (recombine — join reads both branches)
            |
           sum

count is referenced twice, so it is a shared apex node: the interpreted engine runs it once per cycle and fans the tick out to both branches, and the compiled engine emits it once and feeds both join inputs from the same slot.

Why

Answers the question "can the dual-mode graph! macro handle a split/recombine diamond?" — yes. The macro derives the full DAG from the wiring tokens (shared/fan-out nodes and multi-input recombine ops like join/merge), so nothing is limited to linear chains. Updating the canonical dual-mode example to a diamond makes that explicit in the one example most likely to be read first.

Testing

cargo run -p wingfoil-next --release --example dual_mode:

diamond sum of (2i + i^2) over 200000 cycles: 2666726666900000 (both engines agree)
interpreted: 29.6ms  (148.2 ns/cycle)
compiled:     9.7ms  ( 48.7 ns/cycle)
speedup:      3.0x

cargo fmt --all -- --check and cargo clippy -p wingfoil-next --example dual_mode -- -D warnings both pass.

🤖 Generated with Claude Code

---

Generated by Claude Code