Neither client concretely checks that it's on the wrong chain: BCH and BSV had an unclean split.
Neither changed the network magic, nor did either change their transaction format, so their nodes continued to communicate and transactions remained replayable from one network to the other. As MCCCS mentions, the two networks started following distinct best chains when each side included transactions that were invalid to the other network. At that point, full nodes were still connected to a mix of nodes of both protocols. They'd get announcements for blocks of either chain. As they download the first block with the new op-codes that were only permitted on one or the other protocol (
OP_DATASIGVERIFY), nodes would try to validate the block, and find the other protocol's block invalid. At that point, they'd ban the node that offered the invalid block and replace the peer with another connection. I think that they'd then at least disconnect or outright ban any new peer that also follows the (from this node's perspective) invalid chain when they get connected. This presumably caused peer churning on both sides until every node eventually made sufficient connections to nodes running the same protocol as themselves.
The screenshot you linked was posted about ten days after the split, so the topology reorganization may have still been on-going at that point (or the screenshot was created a few days before it was (re-)posted).
Especially services monitoring node population could also have been running special crawler-nodes that weren't actually running full node software and thus not announcing blocks, so those would have perhaps lagged behind on noticing the topology split.