Bugfix: Separate login and message replay timestamps to allow companion RTC differs from app clock

[usrflo]

Summary

Properly fixes the silent-message-rejection issue that was also addressed in #1551 and #1889.
It does so by tracking login replay and message replay in two separate per-client fields instead of sharing one to fix clock/timestamp differences at the client. This uniformly applies to room-server, repeater and sensor.

Fix

Split the two replay tracks:

• Add a transient field ClientInfo::last_login_timestamp.
• The login replay check and the login timestamp assignment use last_login_timestamp.
• The message/REQ handlers are unchanged and keep using last_timestamp.

Result:

• Login replay now runs purely on the companion RTC. Because getCurrentTimeUnique() is monotonic per device, every login's timestamp strictly exceeds the previous one → repeated logins work again (regression fixed).
• Message replay still runs on last_timestamp, which is no longer poisoned by the login's RTC value → messages are no longer rejected when the RTC runs ahead.
• The forward-only RTC sync (clock sync / time refuse to go backwards) no longer matters, because the two replay tracks are independent.

Backward compatibility

No wire-protocol change. Old clients keep working against a patched server (the server just tracks login and messages separately), and patched clients work against an unpatched server.