Critical Bug: Clock Drift and Startup Race Condition in Stale Message Filtering

The introduction of _is_stale_message to filter out messages where timestamp < self._session_started_at introduces two severe issues that can permanently stall the connection handshake:

1. Startup Rendezvous Violation:
   As documented in the comments for start() (lines 59–63), a peer whose connect_to runs before this agent registers will write qp_ready to our stream before our listener/session starts. In this valid scenario, the message's timestamp will naturally be less than self._session_started_at. By classifying these messages as stale and ignoring them, the agent will fail to establish the connection, stalling the handshake forever.

2. Distributed Clock Drift:
   The timestamp is generated using the local system clock of the sending peer or the control plane (time.time()), while _session_started_at is generated using the local system clock of the receiving agent. In a distributed environment, even minor clock drift (e.g., if the sender's clock is slightly behind the receiver's clock) will cause newly sent, perfectly valid messages to be incorrectly discarded as stale.

Suggested Remedy:

Instead of using absolute wall-clock timestamps from different machines to detect stale messages, consider using a unique session/run identifier (e.g., a UUID or an incrementing epoch/incarnation number generated during registration) that is passed in the messages. Alternatively, rely on the fact that cleanup_agent already deletes the stream key upon deregistration/restart, or use Redis stream IDs (which are monotonic and generated by the single Redis server clock) to establish a safe boundary.