fix(l1): fix callTracer log index under onlyTopCall and in debug_traceCall

[MysticRyuujin]

This makes the callTracer withLog output follow the log index rules that ethereum/execution-apis#855 adds to call-tracer.yaml.

The spec defines CallLog.index as "the log's index within the block: the number of logs that took effect in the block before this one, counting the logs of all preceding transactions. It MUST equal the logIndex of the same log in the transaction receipt. Logs of reverted frames never take effect and do not consume an index, and onlyTopCall does not change the numbering. For debug_traceCall, where no receipt exists, numbering starts at zero for the traced call." For position it says: "When onlyTopCall is set, no subcall frames are collected and position is 0 for every log."

Two things in ethrex do not match this.

Under onlyTopCall the tracer never pushed nested frames, so the callframes.len() > 1 guard in log() never fired. Every nested log landed on the root frame, including logs of nested calls that reverted, and the root log got a transaction-local index. The tracer now always builds the full frame tree. After it prunes reverted logs and assigns indices on the top frame, it drops the root's calls and sets every remaining position to 0 when onlyTopCall is set. The root frame's gas, output and error fields do not change. Because trace_block_calls counted the logs of the returned trace to seed the next transaction, and that count would now miss the hidden nested logs, run_call_trace returns the tracer's next log index instead and count_call_logs is gone.

debug_traceCall without txIndex seeded the index from the receipts of the whole block. It now starts at 0. With txIndex it still counts the logs of the replayed transactions, which is what geth's StateAtTransaction state does. Reviewers may want to decide whether txIndex should also start at 0; the spec sentence quoted above does not distinguish the two.

The spec fixture calltracer-only-top-call-with-log traces the calltree transaction with {"onlyTopCall":true,"withLog":true} and expects exactly one root log with "index":"0x2" (two nested logs precede it and are not reported), "position":"0x0" and no calls key. The existing calltracer-with-log-index fixture expects "index":"0x3" for a transaction that follows one with three logs.

Hive cannot verify this against ethrex today. ethrex rejects the execution-apis test chain before London because the base fee header check runs on pre-London blocks (#6954), so the rpc-compat simulator never reaches these tests. Unit tests cover the change instead: trace_call_calls_only_top_call_keeps_block_absolute_log_index, trace_call_calls_only_top_call_ignores_reverted_nested_log and trace_call_log_index_starts_at_zero_on_top_of_the_block. All three fail on main and pass with this change.