fix[next-dace]: reject state fusion when a transient is written in both states

[edopao]

Problem

The stree lowering of concat_where emits a transient array that is partially written in two consecutive SDFG states: each state writes a disjoint subset of the transient, with symbolic Max/Min bounds, and the second state also reads it. DaCe's own SimplifyPass cannot reason about those subsets, so it does not rewrite anything. GT4PyStateFusion then merged the two states anyway.

After the merge, the consumer rewiring in apply() only reconnects source nodes of the second state, so the first state's write to the transient was left disconnected from the second state's read. DeadDataflowElimination subsequently deleted the dangling write, leaving the output partially uninitialized at runtime.

Per ADR-018, a transient must be written within a single state, so such a configuration is invalid input for fusion.

Fix

GT4PyStateFusion._check_for_wcr_conflicts now checks the common_write_data (the arrays written by both states) and reports a conflict — refusing the merge — when any commonly-written array is transient, in line with ADR-018's "a transient must be written in a single state" rule. The two states are left separate, preserving the dataflow edge from the first write to the second state's read.

Tests

• Added regression test test_transient_in_both_states_write (with factory _make_transient_both_states_write) reproducing the concat_where pattern: two states writing disjoint slices of a transient t, the second state also reading it. It asserts that apply_transformations_repeated(GT4PyStateFusion) applies 0 times and that both states survive intact.
• The full transformation_tests/test_state_fusion.py suite passes (15 passed).