[sduchesneau]

Fixes the balances the inspector records when one account's balance changes several times between two journal reads, and prepares the base-v2.5.2.8-fh3.1-2 release notes.

• Each balance change read from the journal took the account's final balance as its new value. An account changed twice in one read showed the final amount twice. On Base, a type 0x79 transaction whose payer is also the block beneficiary gets its refund and its tip after the last call, read together at the root call's end: the tip was counted twice, and both credits were labelled GasRefund.
• balances_after_entries walks the batch backwards from the final balances, so each BalanceChange / BalanceTransfer ends where the next change of that account starts (AccountDestroyed is followed too). An account with one change per read, which is every case outside Base's 0x79 path on this branch and on release/reth-2.x, gets exactly the same values as before.
• RootJournalReasons: an account listed several times takes its reasons in list order, one per change, and keeps the last one. revm journals no entry for a balance write that moves nothing, so a payer that is also the beneficiary and gets no refund has its tip labelled GasRefund; the amounts stay right.
• New test root_journal_reasons_split_two_credits_of_the_same_account checks the old/new values and reasons; it fails with the previous reads. 35 reth-firehose tests pass, no new clippy warnings.

After the tag, Base passes (beneficiary, RewardTransactionFee) after the payer's refund entry, which it already does.