fix(sequencer): gate waitForMinTxs on age-eligible pending tx count

[spalladino]

Context

waitForMinTxs decided whether enough txs were available to build a block by polling p2pClient.getPendingTxCount(), which counts all pending txs regardless of age. The block builder, however, only iterates txs older than minTxPoolAgeMs (2000ms in production). When a fresh burst lands on a near-empty mempool the gate returned canStartBuilding: true immediately while the eligible iterator yielded zero txs, so the builder threw InsufficientValidTxsError and the sub-slot was wasted (worst case on the last sub-slot: an empty checkpoint and a skipped slot). The gate never actually waited for txs to age in.

Approach

Add an age-aware predicate hasEligiblePendingTxs(minCount) through the tx-pool → P2P → client layers and gate block building on it instead of the raw pending count, so the gate and the builder agree on age eligibility and the poll loop waits for aging (bounded by the existing startBuildingDeadline).

A predicate rather than an eligible count: the gate only needs to know whether at least minTxs eligible txs exist, and minTxs is typically 0 or 1. hasEligiblePendingTxs early-exits as soon as the threshold is met and short-circuits in O(1) when the total pending count is already below minCount (eligible txs are a subset of pending), instead of scanning the whole pool on every poll. getPendingTxCount() stays O(1) and is reused only for the informational tx count in logs/events; its semantics are unchanged. The two automine sequencer gates switch to the same predicate (a no-op under automine's minTxPoolAgeMs=0, kept for consistency).

API changes

New hasEligiblePendingTxs(minCount): Promise<boolean> on the internal TxPoolV2 and P2P interfaces (and the TxPoolIndices/TxPoolV2Impl layers). No public RPC change — stdlib's P2PApi is untouched.

Fixes A-1251