fix: poll getLogs instead of eth_newFilter for L1 event watchers

[spalladino]

Context

The node's five L1 event watchers (slasher rotation, slashing votes/rounds, checkpoint invalidation, slash events) used viem's watchContractEvent, which installs a server-side filter and polls eth_getFilterChanges. Server-side filters die in the field: load balancers route polls to backends that never saw the filter, and providers report purged filters with error codes viem does not treat as "filter gone" (reth -32602, Alchemy -32600; erigon returns an empty result with no error). Watchers then either churn recreating filters or hammer a dead filter id at the poll rate — operators reported 30-40 req/s of spam — while silently missing slashing and governance events.

Approach

Replace the viem watchers with a custom poller, watchContractEvent in @aztec/ethereum. An earlier revision of this PR instead excluded the filter RPC methods at the transport level to force viem into its built-in getLogs fallback, but that fallback retries filter creation on every tick and issues a single unbounded eth_getLogs when catching up after an outage, so we now own the loop:

• Each tick polls eth_blockNumber (viem caches it per client at the client's polling interval, so concurrent watchers share one request) and fetches new logs with eth_getLogs via client.getContractEvents, never touching filter RPCs. Requests never span more than a configurable maxBlockRange (default 100) blocks: catch-up after downtime is chunked into multiple bounded requests, and the cursor advances per successful chunk so a mid-catch-up failure retries from where it left off instead of losing blocks.
• The helper is strongly typed on the event via viem's ContractEventName / GetContractEventsReturnType helpers (including strict decoding), and is built on foundation's RunningPromise, so ticks never overlap and unwatching interrupts a catch-up loop.
• Per-log callback isolation (a throwing callback or a rejected returned promise is logged without dropping the rest of the batch), and every failed poll logs a warning.
• Poll intervals per event: SlasherUpdated polls every 60s since slasher rotations are rare governance operations; the other four watchers poll at the client's polling interval as before, and only issue eth_getLogs when the head actually advances. All listen* methods accept an options override.
• Tests cover baseline semantics (only events mined after subscription), chunk boundaries, failed-chunk retry from the same cursor, callback isolation, stop-on-unwatch, and an anvil integration test behind a request-recording proxy asserting events are delivered with zero filter RPCs on the wire.

Known trade-offs, documented in the helper's jsdoc: delivery is best-effort with possible duplicates on reorgs (no removed notifications; production consumers treat events as triggers and re-read chain state), and events mined within ~1 polling interval of subscribing may be missed (filter mode had nearly the same window).

Fixes A-1695

[alexghr]

Is it intended that this loop skips the current in progress block? Doesn't this mean we risk missing events in the first L1 block after the Aztec node boots up?

[spalladino]

I think it's not too bad, but fair, we can just remove that +1

[spalladino]

Removed the +1 in 35abe17 — the block that is latest on the first poll is now the starting cursor, so its events get fetched. Events from blocks before startup are still not reported.