Decouple finalization from head ingestion

[kalabukdima]

Problem

The EVM hot-block data service spiked block-lag every ~6.4 min, locked to blockNumber % 32 on Ethereum.
Root cause: when Ethereum finalizes an epoch (~32 blocks at once), the finalizer pushed a burst of finalized-only batches ({blocks: [], finalizedHead}) through the same single output queue as head blocks, serializing ahead of head ingestion and stalling the head-poll loop.

Fix

Take finalization off the data-loading path (evm-rpc/src/data-source/finalizer.ts):

• probe() records the confirmed finalized head in this.current and returns — no output.put({blocks: [], finalizedHead}).
• visit() adds this.current to each head batch's finalizedHead.

output now carries only head batches; the finalized head rides the next head block. Finality lags the head by ~13 min, so a sub-second delivery delay costs nothing. Probe batch size stays at 5 — the RPC requests are not affected.

Benchmark (live Dwellir Ethereum, 3 epochs)

metric	before	after
finalized updates/epoch	~6 burst	1 jump (+32)
residue 12/13 blocks >5000ms	spikes 5–8 s	0
max blockAge	13550 ms	6000 ms
probe batch	5	5

The %32 lock is gone; remaining >5000 blocks sit at scattered residues (normal jitter). Finality advances in correct single +32 jumps.

Why a stalled head can't starve compaction

chain.push (cache growth), chain.finalize, and chain.compact all run in the same per-head-batch consumer step, so the cache never grows without finality being delivered alongside it. A stalled head stops cache growth too. The only residual effect is the reported finalized head going stale during a head stall — conservative (under-reports finality, never over-reports), therefore safe. Genuine non-finality behaves identically to the old code.