pfSense TCP retransmissions flagged as out-of-state: when does sloppy state tracking help?

Goal

I want pfSense to tolerate TCP retransmissions (retries) on a connection without tearing down the state entry or causing the application to re-issue writes, while still keeping stateful inspection strict enough to be meaningful.

Context and constraints

pfSense uses the pf stateful engine: once a packet matches a pass rule, subsequent packets in the flow are matched against the state table by 5-tuple rather than re-evaluated against rules. By default, state tracking checks TCP sequence windows, so retransmitted or out-of-window segments can fail state matching. There is a documented "sloppy" state option per rule that relaxes sequence number checking, and there are state timeout settings under System > Advanced > Firewall & NAT. My concern is a path where latency or asymmetric routing may produce retries that the firewall treats as not belonging to the established state.

Assume a current pfSense Plus/CE release; exact behavior may vary by version, so I plan to verify against Diagnostics > States and Status > System Logs > Firewall.

Questions

1. Does a retransmitted TCP segment that falls outside the current sequence window get dropped and logged as a state mismatch, or is it silently associated with the existing state?
2. When enabling the sloppy state option on a rule, which checks are actually relaxed, and does it increase exposure to injected or replayed segments?
3. Which state timeout values are most relevant when retries arrive long after the original packet?