Keep database and forkchoice genesis consistent with the chain spec

[vmarkushin]

The rollup database could retain the migration’s block-zero row beside the configured chain’s genesis, making safe-head lookup ambiguous. Custom-chain forkchoice initialization also recomputed the genesis header hash instead of using the chain spec’s sealed hash, which differs for Chikyu.

This change uses the sealed genesis hash and reconciles the database’s block-zero rows in one transaction during startup. Fresh databases replace the migration seed; populated databases can remove a duplicate seed only when the configured genesis is already recorded. Startup refuses an unexpected genesis, a populated database missing block zero, or populated history identified only by the shared seed. All refusals preserve the genesis rows and retained history.

Upgrade impact: legitimate older dev databases with only the shared seed also refuse startup because chain ownership cannot be established from that marker. Operators must verify the chain and database path, then restore a chain-identified backup or re-derive into a new rollup database. Existing data is not deleted on refusal. Operator documentation covers the behavior.

Extracted from #45 and based directly on main after #47. Independent of the sequencer-confirmation and credential-redaction PRs.

Validation:

• Node unit suite: 36 passed; Engine unit suite: 2 passed.
• Database unit suite after the review fix: 28 passed, 1 pre-existing ignored test.
• Clippy passed for the affected libraries with existing toolchain compatibility allowances.
• GPT-6 Astra high-effort review found an ambiguous legacy-marker replacement; it was fixed with preservation tests. A fresh full-diff Astra review approved the resulting commit with no blocking findings.

[codspeed-hq]

Merging this PR will not alter performance

✅ 2 untouched benchmarks

---

_{Comparing codex/issue-38-03-genesis-consistency (174a860) with main (8377dc4)}