When you write a React component, there are all kinds of ways where React calls you, e.g. the hook mechanisms. And that can be considered a framework in my opinion.
It also tells you how you should write your components, which is another sign that it's a framework and not just a library.
I may not have been clear enough in my opening sentence discussing the differences though I did go into great detail following it and so I don't think my comment was unclear.
By the logic you just demonstrated, if you call a function that accepts a call-back as a parameter, when it evaluates your callback you are consuming a framework. Or any React component that receives a callback as a prop would suddenly be a framework. Promise libraries would be "frameworks."
Just because a framework executes your code primarily via the application of the Hollywood Principle, and operates primarily through the application of the HP, doesn't mean that any application of the hollywood principle automatically indicates that you are working with a framework.
When getting into discussion about definitions, there is a lot of room for nuance, opinion and degrees. The key part of my definition that you glossed over was [paraphrasing myself]: "skeleton application that provides as much scaffolding, bootstrapping, internal APIs and design decisions as possible leaving you free to focus only on the pieces of your application that are specific to your domain problem."
Yes, you are right it's very nuanced and also a bit subjective. So it doesn't actually make much sense to argue about it, much less here. Anyway, thanks for your comments, they are insightful.
It also tells you how you should write your components, which is another sign that it's a framework and not just a library.