So there could be a case where the segment on the sender’s side gets corrupted the moment it is encapsulated (in the packet; or while the packet that the segment is in gets encapsulated in the frame: so while the segment is still on the sender’s machine), but none of the frames (or the message within the frames, i.e. the packet or segment, or both) get corrupted as the encapsulated segment gets transmitted from the sender to the receiver? In this scenario, the only way to know that the original segment was changed is with the help of the Checksum in the TCP header.
You’re essentially trying to find a situation where the FCS checksum does not fail while the TCP header checksum does, correct? This may occur during encapsulation, as you suggest, which would create an error that is caught only by the TCP checksum and not the FCS checksum.
Another possible scenario is that during transmission, there are multiple bit errors in the TCP segment that is carried by the Ethernet frame as payload. These errors could occur in such a way as to result in no change to the FCS calculation in the Ethernet frame but do change TCP checksum calculation at the destination device. In such a case, the FCS would pass while the TCP checksum would fail.
Again, these are relatively unlikely scenarios. However, due to the massive number of packets and frames sent, they are not an impossibility. Keep in mind that although these two mechanisms do very similar things, the main difference between them is how they deal with an error once it is found. The difference primarily has to do with the layer of the OSI model they are operating in.