Interesting points of view, but to be honest, I do not fully agree with you.

Units should be classes nor methods, even if most of the times are. Units are units of behavior. If you do your unit tests by splitting everything by methods, your unit tests will be fragile on refactoring, and their cost will get pretty high, pretty fast.

Regarding integration tests, I think you're making a confusion between things. With the integration tests you basically verify the communication paths and interactions between components / modules, which are created using multiple units. When you are talking about testing more components (like 2-3 APIs talking together, or maybe to a function or whatever more), in that moment you are thinking towards system tests.

Usually people tend to think there are only 3 types of tests due to the old pyramid of testing (with unit, integration and e2e tests), but nowadays things change, and in distributed systems that is not even relevant anymore. And even in those old days, integration was added as a "big category", since in reality it contained components testing, acceptance, scenario, functional, systems tests and so on.