No.
There is an even simpler scenario for this question, without the client certificate.
You ask, given pcapng / tcpdump / wireshark file of the entire communication session between client and server and an SSLKEYLOGFILE dump in NSS Key Log format so you could decrypt the stored traffic, is that proof that the server sent whatever the file says the server sent?
And the answer is no, it is not.
TLS does not provide non-repudiation. The signature is proof that you communicated with the other party, but it is not proof of when the communication took place (because gmt_unix_time is deprecated) and it is not proof of what was communicated, only that the communication took place (possibly without any application data being sent).
After the handshake, both sides have the same symmetric keys for both sides. Both sides can generate a transcript that shows the other side sent, encrypted and authenticated with the expected keys, any data. There is no way to know whether that is true or not.
To achieve non-repudiation, you would need to add a digital signature at the end of the connection, signing a hash of the entire connection until the disconnect message was received. But there is no such feature in TLS.
Alternatively, you would need your friendly local sigint intelligence agency to provide a packet capture file that they certify is authentic, and one of the sides of the communication to provide SSLKEYLOGFILE dump, and then you would know that some packets were really sent in that direction and the cleartext data.