While debugging the sensors, Minh found some failures to rlp decode blocks, coming from erigon nodes.
The error is error: rlp: value size exceeds available input length
Apparently, blocks containing PIP-74 state sync txs were being encoded with an inflated RLP list prefix, causing peers to fail decoding it.
The root cause has been identified in StateSyncTx.EncodingSize() returning rlp.StringLen(data), which includes the outer RLP string prefix in its return value. All other typed transactions (e.g., AccessListTx, DynamicFeeTx, etc...) return the envelope size without the outer prefix, because the function EncodingSizeGenericList adds that prefix itself via rlp.ListPrefixLen(size) + size. The double-counted prefix inflated the len by some bites per StateSyncTx, which propagated up to the block's outer RLP list prefix, declaring more bytes than were actually written.
The function EncodingSize() has been changed to to return 1 + b.Len() (type byte + encoded payload). This is equivalent to the 1 + rlp.ListPrefixLen(payloadSize) + payloadSize pattern used by other typed transactions. The difference is that StateSyncTx delegates inner encoding to rlp.Encode() which already includes the list prefix in b.Len(), whereas other types compute payloadSize as raw field sums and add the list prefix explicitly. Ofc, this only affects blocks after the Madhugiri fork that contained state sync events.

Furthermore, there were some missing Bor fork IDs in GatherForks(), which only registered Agra, Napoli, and Bhilai for Bor chains. All post-Bhilai forks were missing, so the fork ID checksum didn't potentially change at those boundaries and incompatible peers weren't filtered during the eth handshake. To serve this purpose, I also added IsDandeli / GetDandeliBlock to the BorConfig interface (was the only fork missing a getter) and registered all forks in GatherForks().

All changes are provided with tests.