fix: harden istanbul_status RPC against resource exhaustion and data integrity issues

[eomti-wm]

Overview

This PR hardens the istanbul_status RPC API in the WBFT consensus module by introducing block range limits and epoch-based validator set caching, resolving several reliability issues and resource exhaustion risks.

Problem

• The lack of an upper limit on the requested block range allowed unbounded database scans, exposing the node to CPU and DB I/O resource exhaustion.
• Casting negative block number constants (e.g. LatestBlockNumber) directly to uint64 caused underflow (wrapping), leading to incorrect parsing.
• Failures during block analysis silently fallback to round 0, polluting distribution statistics and causing partial counter updates.
• Inactive validators at epoch boundaries were omitted from the final response, and redundant database header queries occurred on every block.

Solution

• Introduced a maximum request limit constant (maxStatusBlockRange) in calculateBlockRange to restrict scan ranges, and correctly mapped LatestBlockNumber while rejecting other unsupported negative constants.
• Refactored analyzeBlock to return errors explicitly and deferred counter increments until all data fetches succeed.
• Implemented local caching for validator sets refreshed only on epoch boundaries, initializing zero baseline entries dynamically for all active/inactive validators.

Changes

• Add range validation and explicit mapping for rpc.BlockNumber constants in calculateBlockRange
• Redesign analyzeBlock to return (uint64, error) and defer counter updates to prevent partial state corruption
• Implement local caching of validator sets and zero-baseline initialization in the Status loop
• Remove the ambiguous TotalRounds field from RoundStats struct

[hominlee-wemade]

LGTM