Should all third party methods that access outside resources (like other databases) be wrapped up?
Yes, pretty much. See Parnas, 1971. The core idea is that in our designs we create boundaries to insulate the bulk of our code from the specifics of our design decisions. In other words, we're writing our code in such a way that changing a design decision has only local impact.
When you do this, one of the useful consequences is that the boundary that you have created has a character that allows you to replace it with something simpler. Thus, we can introduce a test double to act as a substitute for our module in contexts where use of the module will be problematic (ex: in a test environment).
third party methods can change and become static/final
Yes. Notice, however, that changes to the third party methods will also be challenging on your production code unless you have taken steps to encapsulate it well.
Unstable dependencies create their own problems, which is why we avoid them when we can and take steps to limit the blast radius when we cannot.