core/txpool/blobpool: improve observability for gapped transaction queue #33811
Description
The gapped queue currently only has addGappedMeter for observability, but it fires before the allowance/maxGapped check so it's really counting all nonce-too-high attempts, not actual additions. dropGappedMeter tracks something different entirely (drops from the pool index during recheck, not gapped queue evictions).
It would be nice to know what's actually going on in there — how many txs get in vs rejected, how many get promoted back, how many time out in evictGapped. Right now there's no way to tell if the maxGapped and gappedLifetime defaults make sense in practice without adding some logging and rebuilding, which isn't great.
Opening this to see if there's interest before writing any code. Happy to put together a PR if the direction sounds reasonable.