fix(firehose): handle multi-system Arbitrum blocks

[DenisCarriere]

Summary

• accept Arbitrum blocks containing multiple TRX_TYPE_ARBITRUM_INTERNAL transactions
• attach block-level system calls to the typed index-0 transaction, matching debug_traceBlockByNumber
• defer the whole batch's traces to Blockscout's native RPC trace worker when a multi-internal block is present, while retaining Firehose blocks, receipts, logs, and balances
• ignore out-of-request Firehose boundary blocks after filtering them from the response, while still rejecting missing or duplicate requested blocks
• serialize the Solidity verifier test module because it mutates the global Tesla adapter and uses the singleton Solc downloader

Closes #12.

Why

The Robinhood backfill repeatedly stalled on ranges containing blocks such as 26899013. Firehose reports two Arbitrum internal transactions for these blocks. The block-level system calls belong to transaction index 0, but the later Firehose transaction's call hierarchy does not match the node's debug_traceBlockByNumber response.

Importing those traces would be unsafe. Returning internal_transactions: nil for the affected batch preserves Blockscout's standard pending_block_operations path so its native trace fetcher completes them durably.

Firehose can also transiently return finalized boundary blocks outside the requested range. These are now filtered rather than causing a complete requested range to retry forever.

CI reliability

The Explorer suite failed twice on two different Solidity compiler versions because async verifier tests raced the global Tesla adapter and SolcDownloader. The module is now synchronous, matching its process-global setup and preventing another test's Mox context from leaking into compiler downloads.

Validation

• npm test: 15 tests passed
• focused Elixir Firehose suite: 17 tests passed
• full pinned Elixir dependency compilation and application compilation succeeded
• mix format completed
• patched sidecar fetched known failing live block 26899013 successfully: 1 block, 2 transactions, fallback enabled
• the directly affected EthereumJSONRPC and Indexer CI suites passed before the CI-isolation follow-up
• no new environment variables and no deployment topology changes

Deployment behavior

This keeps one Blockscout indexer. Catchup throughput remains controlled by Blockscout's native batch-size and concurrency settings; only the exceptional ranges use the existing RPC trace worker.