Unfortunately, this is a limitation of Windows as a whole (and, really, pretty much every other operating system as well): a 64-bit process cannot load a 32-bit library. So if you want to load it in Unreal, you’re going to pretty much have to port it to 64-bit.
Any methods to load a 32-bit library in a 64-bit process – and I have seen some really clever workaround hacks – will be a real pain to implement.
As an example, I’ve seen a legacy library loaded on Linux by having a 32-bit application load the 32-bit library, then export all the library functions via DBus and create a 64-bit shim layer that implements the legacy library’s API, but simply calls the functions in the other process. So basically you have a 64-bit process that thinks it has the library, but the function calls actually all go to an entirely different separate program running in the background, which is 32-bit and thus can load the 32-bit library.
Clever? Yes. Overcomplicated? Also yes. (Though in that particular case it was a library from a company that was no longer around, which only existed in binary format and which no one had source code to, so it admittedly wasn’t like there were many other options.)
But needless to say, coming up with a Windows version of that sort of workaround and grafting it into Unreal would be Kind of a Lot of Work… potentially far more than just getting a 64-bit version of the library compiled would be.