I think you're getting too hung up on the TCP connection terminology and how that relates to what Snort means by source and destination.
While Snort does have the capability to keep some state information for stateful inspection (called flowbits) the signatures are processed against individual packets. This means that the source and destination do not map to client and server, they map directly to the source and destination address fields in the IP header. So that means that the specific packet that caused this rule to fire had 10.19.0.5 in the destination address field and 136.238.4.165 in the source address field. We're talking about a single packet here, it has nothing to do with who initiated the session.
Also keep in mind how the sfPortscan preprocessor works. Its detection algorithm really just checks against 3 patterns:
- TCP/UDP traffic where one host talks to one host and hits many ports
- TCP/UDP traffic where many hosts talk to one host and hits many ports
- TCP/UDP/ICMP traffic where one host talks to many hosts on a single port
Largely because of the #3 this alert can be triggered by just about any system that's actually providing a service. For some reason Windows SMB fileservers seem to be the worst offenders for false positives. This makes the sfPortscan preprocessor exceptionally noisy. So noisy, in fact, that unless you have a tightly restricted network, and have the expertise to tune the output significantly, it's almost not even worth enabling this preprocessor.