How can Proxy and Facade design patterns be combined?

I have a third party library class Lib and an own LibProxy where LibProxy adds some caching before passign the control to Lib. This would have been textbook Proxy, but LibProxy also simplifies the interface to Lib. Which also makes it a Facade.

What is the course of action here? Making LibProxy comply to the interface of Lib and adding a separate LibFacade feels like overkill. This is what it would look like: Client->LibFacade->LibProxy->Lib.

Can I call it LibProxyFacade instead? Or is there some other pattern that is equivalent to the Proxy/Facade combination?

I would say don't overthink it: the patterns are there to show us a way of solving some of the common problems, but it doesn't mean they are always the right/only way. I like this talk by Venkat where he is presenting some patterns, but he starts the presentation with the cons of overengineering: https://youtu.be/yTuwi--LFsM?t=238

Back to your question: does ProxyLib really need to implement the same interface as Lib for any reason (other than following the Proxy pattern)? Why not change the interface (and maybe rename the class to something else like LibFacade or LibAdapter?

If you want to implement an interface, I would place it in inside your domain, and have this facade/adapter implement it by mapping, adding some caching, and delegating to Lib. This is called dependency inversion and helps you protect your logic against the changes in the public API of the lib. If this is interesting to you, here is a blog post from Uncle Bob:
https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html