op-supernode: Prevent local-safe promotion while verified state is stale

**Claude:** I found this during the interop implementation review.

An L1 reorg can leave `verifiedDB` ahead of local-safe. During this window, unverified local-safe blocks can receive the safe label.

Event sequence:

1. `verifiedDB` records old-branch block `Y[N]` and its L1 inclusion (`interop.go:597-606`).
2. An L1 reorg resets local-safe to common ancestor `M`, where `M < N` (`engine/events.go:117-128`).
3. The next interop round requests timestamp `N+1` (`interop.go:597-606`).
4. `checkChainsReady` calls `OptimisticAt(N+1)` on every chain (`interop.go:1146-1166`).
5. The target exceeds local-safe, so `LocalSafeBlockAtTimestamp` returns `ethereum.NotFound` (`chain_container.go:559-580`).
6. `observeRound` returns on that error before checking `Y[N]`'s L1 inclusion (`interop.go:620-640`). No database rewind starts.
7. Derivation advances the new canonical branch to `X[K]`, where `M < K < N`.
8. `SafeL2Head` still receives stale verified block `Y[N]` (`engine_controller.go:227-247`).
9. Because `N > K`, `resolveVerifiedAsSafe` returns `X[K]` directly (`engine_controller.go:245-247`).
10. This return bypasses the verified hash checks at `engine_controller.go:249-264`.
11. The next forkchoice update supplies `X[K]` as `SafeBlockHash` (`engine_controller.go:670-686`).
12. Once every chain reaches `N+1`, the L1 check runs and the verified database rewinds.

`X[K]` is canonical and local-safe. It has not passed cross-chain verification, so it must not receive the cross-safe label.

Expected behavior:

- Check accepted L1 consistency even when the next frontier is not ready.
- Never promote local-safe solely because the recorded verified head is ahead.
- Fall back to a canonical verified ancestor, the cross-safe cache, or finalized state.