kona-engine: cross-safe promotion clamp warns routinely after a reset rewinds local-safe

The `warn!` in `EngineSyncState::apply_cross_safe_promotion` means "the promotion source and this engine disagree about the chain" — a verifier bug worth diagnosing. Under interop it also fires during ordinary operation, with nothing wrong, which devalues it exactly when an operator would want to trust it.

**Mechanism.** In `rust/kona/crates/node/engine/src/state/core.rs`, the upper clamp warns whenever the promotion target is ahead of the local-safe head:

```rust
if target.block_info.number > self.local_safe_head.block_info.number {
warn!(target: "engine", ..., "Cross-safe promotion is ahead of the local-safe head; holding at local-safe");
```

An engine reset rewinds the local-safe head to the `find_starting_forkchoice` walkback point, deliberately at least a sequencing window behind the unsafe head. The external verifier has not reset and is not wrong: it still holds its previous cross-safe target, and re-promotes it. That target is now above the rewound local-safe head, so the promotion is clamped and warned about — correctly by the letter of the condition, misleadingly by its intent. It keeps firing on every promotion until local derivation catches back up past the verifier's target, so each reset produces a burst of warnings that indicate nothing.

**The rewind clamp does not address this, deliberately.** #22576 adds a clamp holding the cross-safe head at the local-safe head when a rewind drags it below — but that fixes the invariant and the `INVALID_FORK_CHOICE_STATE` it caused, not this. The clamp moves `cross_safe_head`; the warning's condition compares the promotion target against `local_safe_head`, which the clamp never touches.

Verified rather than assumed: with the rewind clamp in place, rewinding an externally-promoted engine from cross-safe `b5` down to `b2` and then having the verifier correctly re-promote `b5` still holds the promotion at `b2` and still warns. Whatever fixes this has to change the warning's condition, not the head arithmetic.

**Two candidate directions**, not chosen between here:

1. **Suppress while the engine knows it is behind.** The engine can tell that it has rewound and not yet caught back up, and treat a promotion above local-safe as expected for that window. Silences the burst precisely where it is uninformative, at the cost of state that has to be maintained and correctly cleared — and of a genuine verifier disagreement going unlogged if it happens to land inside the window.
2. **Narrow the condition to what actually indicates disagreement.** A promotion ahead of a local-safe head this engine simply has not derived up to yet is not a disagreement about the chain; a promotion naming a block that conflicts with one this engine has already derived is. Distinguishing them is the more faithful fix, but needs a comparison the state does not currently carry.

Neither is a small change, and both interact with what the interop wiring makes observable, so this is filed rather than folded into #22576.

**Scope.** Only reachable under `CrossSafeSource::Promoted`, i.e. once the interop wiring feeds cross-safe promotions from an external verifier. Cosmetic in the sense that no head ends up wrong — but a warning that cries wolf on every reset is a real operability problem. Related: #22525, #22576.

---
_Generated by [Claude Code](https://claude.ai/code)_

Start in rust/kona/crates/node/engine/src/state/core.rs at EngineSyncState::apply_cross_safe_promotion and inspect how the reset walkback and cross-safe promotion state interact. Reproduce the described rewind from cross-safe b5 to b2 followed by re-promotion of b5, with #22576 in place. Done means routine post-reset promotions no longer emit misleading warnings while genuine verifier disagreement remains observable.

Written by the indexing model from the issue text.