.htaccess is unlikely to be sufficient (of course, in principle .htaccess is just a place for local configuration, it depends on which modules are available too).
EDIT: (more details on why mod_rewrite/redirect) doesn't work)
Assuming that by .htaccess you're referring to the usual mod_rewrite/redirect directives, this will not work because the browser will be redirected, so the actual (redirected) URL will be visible in the location bar (http://mydomain.com/clientsdomain.com/wordpress), not the one initially requested (http://clientsdomain.com/).
Redirect and RedirectMatch will of course perform an external redirection: this will not maintain the old domain in the URL as requested.
mod_rewrite and RewriteRule provide two options for external links (see table at the end of the documentation (and the documentation about the flags):
^localpath(.*) http://otherhost/otherpath$1
http://otherhost/otherpath/pathinfo via external redirection
^localpath(.*) http://otherhost/otherpath$1 [R]
http://otherhost/otherpath/pathinfo via external redirection (the [R] flag is redundant)
^localpath(.*) http://otherhost/otherpath$1 [P]
http://otherhost/otherpath/pathinfo via internal proxy
The external redirection option (no flag or [R]) will be equivalent to Redirect and cause the URL in the address bar to change.
The internal proxy option ([P]) will not cause the URL in the address bar to change, but, unless the server behind the internal proxy is aware it needs to change the base URLs in the links it serves, this will cause problems with the links embedded within the page (this is what mod_proxy_html can address).
There are at least two possible options to keep the requested URL in the location bar:
iframe
Keeping the original URL is typically done with an iframe. You could write a quick script (e.g. in PHP) that takes a URL (or part of it) as a query parameter.
For example, http://clientsdomain.com/redirect.php?location=some/page would create a page simply containing an iframe for http://mydomain.com/clientsdomain.com/wordpress/some/page. To make all the pages redirect from http://clientsdomain.com/, you could use a rewrite in .htaccess to redirect.php?$1.
In this context, http://clientsdomain.com/some/page would be rewritten as http://clientsdomain.com/redirect.php?location=some/page, which would contain an iframe pointing to http://mydomain.com/clientsdomain.com/wordpress/some/page.
One of the downsides is that, whenever a user clicks on a link the location bar will not change. It might also confuse some JavaScript scripts relying on the fragment (#).
mod_proxy_html
Another solution, possibly harder to install especially if you're on a shared host, would be to use mod_proxy_html to reverse proxy http://clientsdomain.com/ to http://mydomain.com/clientsdomain.com/wordpress.
This might be doable with .htaccess only (provided the module is installed), but I'm not sure: it depends whether its configuration directives are allowed in .htaccess or need to be in the global configuration. Either way, you'll almost certainly need full access to the Apache Httpd installation to configure this, so whether it's in .htaccess or in one of the main config files shouldn't really matter at this stage.
(A plain reverse proxy with mod_proxy_http without mod_proxy_html would allow you to proxy the requests, but wouldn't replace the links within the pages.)
Adding to this, you'll probably need mod_header on top of this (with any of the mod_proxy_*). The Location headers are absolute URLs according to the HTTP specification, so any redirect sent by the proxied server to itself (even simply for adding a trailing slash, for example) will have absolute URLs to itself. You can fix this problem using something along these lines (check whether the regexp and paths are correct when deploying):
Header edit Location ^http://mydomain.com/clientsdomain.com/wordpress http://clientsdomain.com/
(This being said, if the target Wordpress server is not to be used with its initial address, there may be an option or plugin to set its base URL to the new one, which could make mod_proxy handling easier.)
