ethereum: fix non-transitive trigger ordering causing sort panics

[alter]

Fixes #6071

What is going on

EthereumTrigger::cmp compares Call triggers (and Call/Log pairs) by transaction_index, but compares Log/Log pairs by log_index alone, ignoring transaction_index entirely:

(Self::Call(a), Self::Call(b)) => a.transaction_index.cmp(&b.transaction_index),
(Self::Log(a), Self::Log(b)) => a.log_index().cmp(&b.log_index()),

Those two comparisons only agree when log_index happens to increase in lockstep with transaction_index for every trigger in the set being sorted. That is not guaranteed for every trigger source. When it doesn't hold, the combined ordering stops being transitive.

Concretely: a Log in an earlier transaction with a high log_index compares as greater than a Call in the same transaction (correct: events come before calls in a transaction), and that Call compares as less than a Log in a later transaction (correct: earlier transaction sorts first) -- but the two Logs compare directly by log_index alone, so the earlier-transaction Log can come out greater than the later-transaction Log if its log_index happens to be higher. a < b, b < c, but a > c.

This is what crashes graph-node in production with:

thread 'tokio-runtime-worker' panicked at library/core/src/slice/sort/shared/smallsort.rs:860:5:
user-provided comparison function does not correctly implement a total order

inside BlockWithTriggers::new_with_triggers, which calls trigger_data.sort() on a freshly built Vec<Trigger>.

Fix

Key the Log/Log comparison on transaction_index first, falling back to log_index only as a tie-breaker within the same transaction -- the same primary key already used by the Call/Call and Call/Log comparisons. Also rewrote the Call/Log and Log/Call arms with Ordering::then to drop the duplicate guarded/unguarded arm pairs, since both arms now share the same primary-then-secondary-key shape.

Testing

Added test_trigger_ordering_is_transitive in chain/ethereum/src/tests.rs, using the existing create_log test fixture. It constructs the minimal counter-example (a Log in transaction 5 with log_index 50, a Call also in transaction 5, and a Log in transaction 6 with log_index 10), asserts the three pairwise comparisons are consistent, and asserts sorting the Vec doesn't panic.

Confirmed the test fails against the pre-fix code with exactly the expected assertion (log_a.cmp(&log_c) returns Greater instead of Less), and passes after the fix.

Ran cargo test -p graph-chain-ethereum --lib (60 passed, including the two pre-existing trigger-ordering tests), cargo fmt -p graph-chain-ethereum -- --check, cargo clippy -p graph-chain-ethereum --lib -- -D warnings, and cargo check -p graph-chain-ethereum --release, all clean.