fix(net): prevent hello message replay - #6972

[MUST] This check only rejects old timestamps. A timestamp beyond the future side of the window, or an extreme value that overflows the subtraction, is accepted and cached, causing subsequent normal Hello messages to be rejected for a long time. Use an overflow-safe two-sided comparison (timestamp < now - threshold || timestamp > now + threshold) and add future-timestamp coverage.

I agree that we should validate both sides of the timestamp window. If an SR's clock is ahead, a future timestamp with a valid signature can be cached. Even after the clock is corrected, normal Hello messages will still be rejected because their timestamps are lower than the cached value. Block timestamp validation does not resolve this recovery issue. I will use timestamp < now - threshold || timestamp > now + threshold and add tests for future timestamps and extreme values, verifying that normal Hello messages are still accepted after invalid timestamps are rejected.

[MUST] The getIfPresent → signature verification → put sequence is not atomic. Replays of the same address/timestamp on different channels can pass concurrently and both add trust. After signature verification, commit the timestamp with an address-scoped atomic compare-and-update or equivalent lock, and add a concurrency test.

Exploiting this scenario requires first obtaining a Hello message with a valid witness signature that is still within the freshness window, then replaying it concurrently over multiple connections. Given these prerequisites and the added complexity of synchronization or atomic update logic, we will retain the current implementation without adding concurrency control in this PR.