chore(op-node): Fix light-sequencer follow-source ↔ sequencer oscillation during recovery

## Summary

When an op-node is both a sequencer and a follow-source follower (the "light sequencer" config), recovery from a divergence between its unsafe head and the upstream safe chain oscillates, making net progress of ~1 block per 2 poll cycles (~4s/block on a ~2s poll)
instead of converging directly. This roughly doubles convergence time and wastes a forkchoice reset on every other cycle.

Surfaced while de-flaking `TestSupernodeLightSequencerInteropInvalidMessageReplacement` (#21806). That PR fixed the test; this node behavior is unchanged and needs its own fix.

## Mechanism

FollowSource already forceResets onto the upstream on divergence (the #21119/#21155 fix), but the sequencer rebuilds a block on its own fork before the next poll lands — so the follower re-diverges and gets reset again. Net advance is ~1 block per 2 cycles:
convergence is bounded, not stalled, but runs at half the achievable rate.

## Proposed direction

Make the follow-source forceReset resist being clobbered by the next sequencer build during recovery — e.g. hold sequencing until the reorg consolidates (upstream safe matches locally), so the sequencer rebuilds from the settled head rather than racing the next poll.
Should roughly halve convergence time. Not a liveness bug — recovery completes — so this is wasted work, not a stall.

## References

- Test-side de-flake: #21806
- Prior follow-source reorg fixes: #21119, #21155

Start by reading TestSupernodeLightSequencerInteropInvalidMessageReplacement and tracing the follow-source forceReset and sequencer recovery paths, using #21119 and #21155 for context. Done means recovery no longer oscillates: the local sequencer waits for the upstream safe head to settle, convergence reaches the expected rate, and the interop scenario remains covered.

Written by the indexing model from the issue text.