While I generally would also consider React more a library than a framework, I think there are arguments to be made that it's a framework. If we go by the common "your code calls a library; a framework calls your code" distinction, then you definitely have to structure your components in a very specific manner so that the React internals can "call your code" to e.g. render one component from it's parent component.
Compare that to Laravel or anything else that is obviously a framework. You write code and put it in a file in the right place, and it gets picked up automatically, most of the time.
This makes me still consider React a library, rather than a framework. But then there are tons of frameworks that uses React, nextjs is probably one of the more common ones.
With Rails nothing will happen unless you call `run Rails.application` or run the `rails server` command. That doesn't make it a library.
We can do this all day...
Contrast that with rails where you run `rails new $app`, then `rails server` and everything is made for you.
Not sure why you're mentioning vite here, we're explicitly talking about React and Rails, not wrappers or tooling around them.
It fills the exact same role as `rails new $app` does of scaffolding a project, which apparently is a hallmark of a framework. So where does "wrappers or tooling around them" start and end? Why shouldn't we count `create-react-app` (which was maintained by the React team), but count `rails new`?
All this just goes to show that the "you have to call the entrypoint" distinction you are trying to declare is just as fuzzy as most other library vs. framework definitions.
There is next to no difference in hand-writing an essentially fixed entrypoint of React.render vs. getting that file autogenerated vs. calling a "binary" (that is also just an interpreted script that contains the same entrypoint).
If having a entrypoint function/object is enough to call something a library then both Spring Boot and Spring are just libraries. But in reality they are not - so entrypoint rule is not correct.
Furthermore, you can hand configure Spring. If anything, the framework here is the Java servlet container, not Spring. Spring just usually lives within that context.
And at this point I'm not sure if that's completely true either. It's common to embed the servlet container - this is how Spring Boot works. I assume you can do that with raw Spring considering that's what Boot does, but I never bothered trying because I would just use Spring Boot at that point.