fix: validate block state existence before reorg to prevent DB corruption

[rdin777]

Summary

This PR adds a crucial safety check during the node initialization process when the --init.reorg-to-block-batch flag is used. It addresses the issue where the node attempts to perform a reorg to a non-existent state, leading to irreversible database corruption (ref #4098).

Technical Details

Previously, the reorg logic would proceed even if the target block's hash or state was missing from the local database. This caused subsequent components (like the Inbox and Sequencer) to fail with fatal "failed to get previous message" errors, often leaving the DB in an inconsistent state.

Changes:

• Added validation in cmd/nitro/init.go within the openInitializeChainDb function.
• Uses rawdb.ReadCanonicalHash and rawdb.ReadBlock to verify that the target batch is actually present in the database before any head manipulation occurs.
• Implemented a clean exit using log.Crit and a descriptive error message if the validation fails.

Impact

This prevents users from accidentally bricking their nodes when attempting advanced reorg operations on incomplete or pruned databases.

Closes #4098

[CLAassistant]

All committers have signed the CLA.

[github-actions]

Thank you for your contribution. However, this PR has been automatically closed because it was labeled as trivial. As stated in our CONTRIBUTING.md:

---

Important

Please, do not send pull requests for trivial changes; these will be rejected.
These types of pull requests incur a cost to reviewers and do not provide much value to the project.
If you are unsure, please open an issue first to discuss the change.
Here are some examples of trivial PRs that will most-likely be rejected:

• Fixing typos
• AI-generated code
• Refactors that don't improve usability

---

We appreciate meaningful contributions!

[rdin777]

Hi @joshuacolvin0, I believe the 'trivial' label might be a misunderstanding. This PR addresses a specific edge case where a missing block state validation during a reorg leads to database corruption. This isn't a typo fix or a simple refactor; it's a data integrity safeguard. I'd appreciate a manual review of the logic.