I was somehow convinced that the TCP checksum was a header checksum (similar to the IP checksum), but I'm now having doubts reading the Wikipedia article:
The checksum field is the 16 bit one's complement of the one's complement sum of all 16-bit words in the header and text.
This seems a little crazy to me that the TCP checksum, which is placed in the header (as opposed to a footer), depends upon bytes sent after the header. This is a hindrance to hardware optimised TCP. Essentially, this nullifies "cut-through" architectures that would start sending the TCP header before knowing the text of the TCP packet.
Why is the TCP checksum placed in the header when it depends on the text? Can this be mitigated for "cut-through" architectures?
Yes, the checksum is in the TCP header. Rather than check wiki you can go to the references here: RFC 793 Specifically read section 3 paragraph 1.
When you mention cut-through I assume referring to switching. The switch isn't changing anything in the packet payload so there would be no need to recompute the checksum.
I think you could start with scapy to do packet manipulation in real time.