Fix nondeterministic Loop output binding with multiple state variables

[Amir Fathi (AmirF194)]

_translate_loop_stmt computes loop_state_vars once (vars_def_in_loop.intersection(exposed_uses | live_out)) and reuses that same set object for the loop body's parameters, the loop body's outputs, and the Loop node's loop-carried inputs, so those three always agree with each other.

outputs, the list used to bind each Python variable name back to a result value, is built separately as list(loop_state_vars | scan_outputs). A set union creates a new set, and its iteration order can differ from loop_state_vars's own order under CPython's hash randomization even though it holds the same elements. ONNX's Loop op matches inputs to outputs positionally, so when the two orders diverge, the converter binds a Python variable to the wrong computed value.

Fixed by making loop_state_vars a list where it's first computed, and building outputs by concatenation instead of a set union, so all four consumers walk the same order.

With 5 loop-carried state variables, about a fifth of PYTHONHASHSEED values reproduced the swap for me, which matches the "sometimes correct, sometimes wrong" symptom in the report. furthest_sampling's own while loop has 4.

Fixes #2203

Verification:

• Added tests/loop_test.py::test_loop_state_var_output_order_matches_eager, a 5-state-variable loop run under 3 fixed hash seeds (3, 4, 8) that compares eager output to the exported model's onnxruntime output. On main it's red on all three seeds; on this branch it's green.
• pytest tests/loop_test.py onnxscript/_internal/converter_test.py: 56 passed, same pre-existing skip/xfail/xpass on both sides.
• ruff check and ruff format --check clean on the changed files.

Didn't reproduce the reporter's own furthest_sampling model (needs torch); the test above hits the same code path with a smaller repro.