Parallel exec: calcFees coinbase==burnt exclusivity should match serial on burnt-contract chains

Follow-up from PR #21536 review (yperbasis, exec3_parallel.go `calcFees`).

## Context

In the parallel executor's `calcFees` (`execution/stagedsync/exec3_parallel.go`), the handling of the case where the block **coinbase is also the burnt-contract address** (`coinbase == burntContractAddress`) is not a verbatim match of serial semantics.

The base/serial behavior in this corner was itself arguably broken — it drops the tip in the coinbase==burnt case — and the current parallel head is arguably *closer* to correct serial semantics than a verbatim restore would be. Rather than a verbatim restore in #21536 (which is a mechanical type refactor and shouldn't change this behavior), the decision (with the reviewer) was to track the reconciliation here.

## Task

Decide and implement the intended behavior for `coinbase == burntContractAddress` chains so parallel and serial agree:

- Confirm what serial actually does today (does it drop the tip when coinbase is the burnt contract?).
- Decide the correct semantics (likely: parallel should match serial exactly, whatever that is, or both should be fixed if serial is wrong).
- Add a regression test on a burnt-contract chain (coinbase == burnt address, non-zero tip) asserting parallel == serial gas/root.

## Notes

This is an EIP-4844/EIP-7708 burn interaction on an unusual chain configuration (burnt-contract chains), not mainnet-reachable in the common case. Low priority but should not be left as a silent divergence.