You are fully correct - using a DI framework will most probably make your code dependent from that thing. Actually, that's nothing very surprising, since this is typically true for every other framework or foundation library, especially when that lib supports your project with some generic features used everwhere in your code. For example, when you decide to use a certain UI framework or Web framework, this decision is hard to change afterwards as soon as you have build a certain amount of code based on that library. When you decide to use a specific (maybe non-standard)
String class, you cannot easily change that decision later. Such a decision is an architectural one, it is like choosing a certain programming language and try to change that decision after you have written >100K lines of code.
Having all of your code depend on a certain framework might not be a problem as long as it does what you expect from it, and as long as it is properly maintened. But it can become an issue if that's not the case. There are some strategies how to deal with that situation:
choose a framework from a vendor you have faith in that he can deliver you updates and new releases for several years from now
choose an open source framework which has few enough lines of code (and a proper license), so you can do any maintenance on your own, given the vendor vanishes from the market
write your own framework
live with the situation as long as the vendor is available, and when he really vanishes, choose a different framework and try to create an adapter which emulates the old framework using the new
The idea of creating a wrapper library beforehand is not new at all, but I have seldom seen that working, since you would have to make assumptions for a future situation for which you don't know if or when it will hit you, and what the "new" framework will look like. On the other hand, some years ago we successfully exchanged a complete UI framework in a C++ project with ~120K of lines of code by applying the adapter strategy I mentioned above.