Discussion: support payout tx payee being different than fee recipient

As it stands now, block validation requires the `to` field of the payout transaction to be that of the fee recipient.

This is problematic as reorgs still do happen in eth PoS. The payout tx can make its way into the mempool, and into a future block. Even though one would set a max priority of 0 it can still be picked up by clients who've configured their nodes min priority to be zero.

A builder would be especially prone to this if they're seldomly building blocks. That payout tx won't be invalidated until their nonce is bumped (i.e. until they get another block in and perform another payout) so it can sit in the pool for e.g. hours. waiting for a builder with their configured max priority = 0 to pick it up.

This isn't theoretical, I've seen it happen a few times already.

One workaround is to do a 2-step payout. Step 1 - create a tx that funds a contract; step 2 - have this contract address pay the fee recipient with a block number and/or base fee check (to catch re-org).

However, my suggestion is to change the validation rules to remove the `to == fee_recipient` check, and instead validate that the total payout to the fee recipient is `>= bid.value`.

No files or tests are named. Start by locating the block-validation rule that requires the payout transaction's `to` field to equal the fee recipient, then trace the existing payout and bid validation paths. Done means the validation behavior and reorg-related cases are specified and covered by tests, including the proposed total-payout requirement.

Written by the indexing model from the issue text.