Chore: Ensure Backward Sync Correctly Handles Finalized Block Hash

[pr9t]

PR description

This PR addresses a bug where backwards sync should correctly handle the finalized block hash 0x0000..0000.

Added an if condition in MergeCoordinator.updateFinalized() to:

• Check if the finalized block hash is 0x0000..0000.
• Log a warning instead of trying to import an invalid block.
• Return early to prevent unnecessary errors.

Fixed Issue(s)

fixes #7966

Thanks for sending a pull request! Have you done the following?

• Checked out our contribution guidelines?
• Considered documentation and added the doc-change-required label to this PR if updates are required.
• Considered the changelog and included an update if required.
• For database changes (e.g. KeyValueSegmentIdentifier) considered compatibility and performed forwards and backwards compatibility tests

Locally, you can run these tests to catch failures early:

• spotless: ./gradlew spotlessApply
• unit tests: ./gradlew build
• acceptance tests: ./gradlew acceptanceTest
• integration tests: ./gradlew integrationTest
• reference tests: ./gradlew ethereum:referenceTests:referenceTests

[siladu]

I'm wondering if 0x00... could be a valid finalized block on a devnet?

[pinges]

Hash.ZERO has the same probability as any other Hash value and could be a valid block hash on any chain. I think we should not exclude Hash.ZERO as a valid finalised block hash.

[pr9t]

I have updated my code to handle Hash.ZERO as a valid finalized block hash.

[siladu]

@pr9t could you please explain what the changes are in this PR now...I think there's nothing to change if we regard Hash.ZERO as a valid finalized block hash?

Would like @daniellehrner's opinion too about the validity since he created the original issue.

[siladu]

atDebug() is better since it delays the evaluation of the log parameters, which most of the time aren't required unless debug logging is enabled.

[pr9t]

Thank you for pointing this out! I will update the logging statements to use LOG.atDebug().