When a professional gives someone an initial estimate, it should be for doing the job “right”. For software that isn’t a one-off, that usually includes investigation/design time, unit tests, integration tests, QA time, and all of the other necessary parts of developing good quality code. If the initial estimate is too expensive or will take too long, then you negotiate which features will be reduced in scope or dropped, or a shortened QA cycle with increased risk.
Dropping unit tests would not be something I would be willing to put on the table as I consider them part of normal development. I might offer to create a “quick and dirty” prototype a feature if we agree we throw away the prototype and do it properly if the client does want that feature.
I don’t hire a master plumber, then second guess the necessity of each of the steps they do to get the job done. Why is your client that deeply involved in your development? When you create a new feature you estimate the time to do it right, including unit tests for the new feature and making any legacy code you’re touching more robust.
It’s unrealistic to expect a client to want to pay for your team to clean up your code to make it easier for the team to work with because the team didn't take the time do a good job the first time around.
The team needs to start factoring unit testing and fixing smelly code into their estimates for everything going forward, instead of trying to get the client to pay to bring old code up to the quality they should have received when they paid for it to be written.