No idea what exactly is going on there but what you have done isn't a component thing to me.
Just because you can put arbitrary "component" object handles inside an array, which allows you to build "entities" does not mean you are component based.
The above is not component based either, it's switching behaviors exactly like a monolithic entity would do. I'll agree that has some very slight flexibility added.
No idea what a "physics" component is supposed to be either. I assume it is a rigid body representation.
Here is ECS, condensed to the its core.
There are no entities. There are only the components.
The message "between the lines" and showcased in the above diagram is: the execution/update of components is independent from other types and can be - in theory - completely asynchronous. I dare everyone in writing a fully async, fully ECS-only system but that's for another time.
So, what does that mean? It means basically the opposite of this:
One idea that came to mind was having a vector of pointers for each type of component and passing the corresponding vector to the corresponding system.
You should really have the components exist in the systems only and link to them on need rather than keep them floating around and putting them back in on need. Seriously, where do you think rigid bodies are going to go each frame? In the physics library. Where do you think the models will go if not in the rendering subsystem? No point really in taking them out: you take out reference / pointers to them and leave them live in their own land using a base class or a proxy of some sort. Internally the subsystem accesses everything it needs while externally you don't.