We tested this configuration also with 2 local caddy instances with 3 different ports for client, client reverse proxy and server.
We noticed that the client reverse_proxy actually added the client_auth certificate to the first message to the server. The server then replied with a message containing the ACME endpoint URLs of the server. But because these URLs contained the port of the server, and not the port of the reverse proxy, all further messages from the client were sent straight to the server, passing by the reverse proxy. This explains why, starting from the second message from the client, no client_auth certificate was added to the communication.
For example, if localhost:4444 is the acme server and localhost :5555 is the reverse proxy, sending a request to http://localhost:5555/acme/root_ca/directory results in following response:
{"newNonce":"https://localhost:4444/acme/root_ca/new-nonce","newAccount":"https://localhost:4444/acme/root_ca/new-account","newOrder":"https://localhost:4444/acme/root_ca/new-order","revokeCert":"https://localhost:4444/acme/root_ca/revoke-cert","keyChange":"https://localhost:4444/acme/root_ca/key-change"}
In this case the client getting this response would automatically send the next message to https://localhost:4444/acme/root_ca/new-nonce.
Unfortunately, finding out every point in the communication where these URLs are used and replacing them is not practicable for us right now.