core/filtermaps: Add pruning support to filtermaps

[JimmyShi22]

This pull request updates the filtermaps system to properly support history pruning by consistently using the historyCutoff value as the default starting block number instead of zero. This ensures that filtermaps operations respect the pruning boundaries and don't attempt to access pruned historical data.

Block number initialization consistency:

• Updated init, getLogByLvIndex, and deleteTailEpoch methods in filtermaps.go to initialize the starting block number with f.historyCutoff rather than zero, ensuring that historical boundaries are respected. [1] [2] [3]
• Modified lastCanonicalMapBoundaryBefore in map_renderer.go to return f.historyCutoff as the starting block when the index range is not initialized, providing a more accurate default.
• Set the initial value of firstBlock to f.historyCutoff in loadHeadSnapshot in map_renderer.go, aligning snapshot logic with the new boundary handling.

These changes ensure that the filtermaps system properly handles pruned historical data by using the historyCutoff as the authoritative boundary for all operations that need to determine starting block numbers, preventing errors when accessing data that may have been pruned from the database.