kona-node: unsafe signer rotation handling differs from op-node

## Summary

After both clients observe an `unsafeBlockSigner` change from A to B:

- op-node accepts A or B for a three-hour grace period; a block verified against B ends it early ([#19981](https://github.com/ethereum-optimism/optimism/issues/19981), [#20063](https://github.com/ethereum-optimism/optimism/pull/20063), [implementation](https://github.com/ethereum-optimism/optimism/blob/611e84758ba8c659a165c8877a7626f6ab2a1e06/op-node/p2p/gossip.go#L461-L497)).
- kona-node accepts only B ([implementation](https://github.com/ethereum-optimism/optimism/blob/611e84758ba8c659a165c8877a7626f6ab2a1e06/rust/kona/crates/node/gossip/src/block_validity.rs#L101-L121)); any other recovered signer is reported to gossipsub as `Reject`, which can lower the relaying peer's score.

So kona can reject an outgoing-signer block op-node still accepts, even when both hold the same current signer. This matters more as rotations of the configured signer become frequent (rotating or multi-sequencer designs — where I hit it, designing a multi-chain handoff with a bounded rotation window). Rotation acceptance is also unspecified: the [P2P spec](https://github.com/ethereum-optimism/specs/blob/2049036afe878a7cb443f513f4e6ca453d90c340/specs/protocol/rollup-node-p2p.md#L310-L337) says only to reject a block whose sequencer signature is invalid.

## Question

#19981 adopted the grace period deliberately, and I found no kona-side decision to omit it, so this looks like a port gap. If parity is the desired direction, I'm happy to submit a small PR with focused rotation-validation tests; if the omission is deliberate, happy to follow the intended direction instead ([#21906](https://github.com/ethereum-optimism/optimism/issues/21906) doesn't currently cover signer-rotation behavior, but it may be the natural home).

Start by reading rust/kona/crates/node/gossip/src/block_validity.rs and compare its signer validation with op-node/p2p/gossip.go, then review the referenced P2P specification. Confirm whether kona-node should match op-node's three-hour rotation grace period, and add focused rotation-validation tests once the intended behavior is decided.

Written by the indexing model from the issue text.