fix(blockvalidation): run the block.Valid integrity floor, coinbase rules included, before the optimistic peer-block add #2077

What happens today

With optimistic mining on for peer blocks (blockvalidation_optimistic_mining_peer_blocks=true), a peer's block is added to the chain before block.Valid runs, and block.Valid then runs in the background. For a body that carries subtrees, nothing ties the coinbase to the header before that early add. So the block's coinbase rules are only checked after the block is already on the chain:

• coinbase finality (nLockTime and sequence), added in fix(blockvalidation): reject blocks whose coinbase is not final, and stop block assembly mining them #2017
• BIP34 coinbase height
• coinbase length (bad-cb-length)
• the shared coinbase rules in model/block_coinbase_common_rules.go

A body with no subtrees is already bound by CheckCoinbaseOnlyBodyBound and rejected before the add.

The flag is off by default, so a default node validates fully before a block joins the chain and is not exposed. The setting's help text says to keep it off "until the block.Valid split lands", but nothing tracked that split until now.

What the split is

Pull the cheap integrity floor out of block.Valid: the checks that prove the body belongs to the header, coinbase binding included. Run it before the optimistic AddBlock. The four coinbase rules above then run at that point against a coinbase known to belong to the block. On a violation the node skips the early add and falls back to full validation, with no verdict on the block and no penalty for the peer.

Moving any single rule earlier on its own does not help. For a body with subtrees, a verdict at that point is a verdict on a coinbase that may not belong to the block, and the other rules stay exposed.

Context

• Raised by icellan on fix(blockvalidation): reject blocks whose coinbase is not final, and stop block assembly mining them #2017 (model/Block.go:1044), deferred to this issue.
• Same exposure as bitcoin-sv/teranode#4844 (coinbase persisted with the invalid-block record).
• settings/blockvalidation_settings.go, OptimisticMiningPeerBlocks: "Known exposure" and "Recommendations".

Done when

• The integrity floor, coinbase binding and the four coinbase rules run before the optimistic add on the peer-block path.
• A test adds a subtree-carrying block with a non-final coinbase under the flag and asserts it is never stored as the chain tip.
• The help text for blockvalidation_optimistic_mining_peer_blocks drops the "keep this off until the split lands" warning, or says what still applies.