core/filtermaps, eth: add debug_getFilterMapsProgress

[locoholy]

Problem

The filtermaps log indexer already tracks useful runtime progress internally,
but operators currently have to infer its status from logs or metrics.

This is inconvenient on large nodes where log indexing can take a long time
after startup or after history settings change. There is currently no RPC
method that reports which block range is already indexed.

Solution

Add debug_getFilterMapsProgress, a small debug RPC method that exposes the
current filtermaps indexing status:

{
  "disabled": false,
  "initialized": true,
  "headIndexed": true,
  "tailBlock": "0x...",
  "headBlock": "0x...",
  "mapsFirst": "0x...",
  "mapsAfterLast": "0x...",
  "tailPartialEpoch": "0x..."
}

The implementation is intentionally debug-only. It exposes the existing
runtime state of the log indexer without changing the semantics of
eth_syncing.

Implementation

• Add a small exported filtermaps.IndexProgress DTO and accessor.
• Expose it via debug_getFilterMapsProgress in eth/api_debug.go.
• Add debug.getFilterMapsProgress() to the JS console bindings.
• Add unit tests for the exported accessor and the debug RPC method.

Test Plan

go test ./core/filtermaps ./eth/... ./internal/web3ext