Integrate your patch+tests into your build process and don't bump on every external lib revision. Maybe that's basically forking, but what would be the issue with doing this for an OSS project dependency?
Yes - this is the answer (if you can't work with upstream). There are many variants to this: monkey-patching, vendoring (local fork), micro-libs that replace a subset of functionality, wrapper libs, etc ...
This is what I do. Sometimes maintainers eventually fix it and sometimes they don't. i am happy when they do of course, but work is fine either way.
Of course i make it a point myself to view each dependency as a significant cost and to work seriously to minimize them. I used to version pin or vendor in the deps, and then subscribe to the security announce DL for all deps, and avoid insane things like npm or mvn, but that has become more difficult and having a conmercial dep scanning service in your CI makes mvn or npm safe enough, but it remains true that code dependencies are a long term cost. for personal stuff, i would rather take OSS code I find and take the few hours it takes to modify it into my standards, leaving attribition, assuming the license allows of course. copy, modify and recombine.