Improve block reward fee calculation timing

[Zyra-V21]

Description

During QA validation, we noticed that a subset of proposed blocks have f_reward_fees=0 and f_burnt_fees=0 in t_block_rewards, even though the corresponding transactions exist in t_transactions and the CL rewards (f_cl_api_reward) are correct.

This happens because processBlockRewards() can read the block's AgnosticTransactions slice before ProcessBlock() has finished appending them via processTransactions(). Both run as concurrent goroutines launched from runDownloadBlocks()

The pattern is similar to the ManualReward timing issue fixed in #242 — the existing processerBook synchronization already tracks slot processing, so the fix is straightforward.

Impact

• Affects f_reward_fees and f_burnt_fees fields in t_block_rewards
• CL rewards and all other fields are correct
• Mostly affects MEV blocks where the builder payload has transactions
• Occurs sporadically depending on goroutine scheduling

Proposed Fix

Add processerBook.WaitUntilInactive() for each block's slot in processBlockRewards() before calling BlockGasFees(), ensuring ProcessBlock() has completed. Same pattern already used in reorg.go:184.