IMO that's not much different than introducing a new variable in your global state to represent the same thing because you didn't realize there was already one there.
If you have a team you need discipline, code reviews, and leadership. No state solution is going to solve this for you.
It is not a matter of discipline. Avoiding this gotcha requires you to manually inspect your entire parent component hierarchy looking for uses of that hook - sometimes that is a plain grep away, but it is a very much invisible error. You also have to be familiar with the inner workings of the hook itself, and any other nested hooks, to verify if they use any local state or not. If it does, and you need to share that state, well, that's a big rewrite which kind of defeats the initial argument.
Maybe extra tooling could be built to avoid this, if we weren't already drowning in linter plugins...
Again this isn't a problem with hooks. You could easily connect a redux store and reducer to some component low in the hierarchy with it's own state. Or use a class based component with some state. A developer can introduce random state anywhere and it has nothing to do with hooks themselves. If you can't trust your team to make the right decisions about where to place state, then you need to provide more guidance.
I also disagree about the big re-write. Converting a hook's data/state to come from a prop instead is a very simple change.
If you have a team you need discipline, code reviews, and leadership. No state solution is going to solve this for you.