It is okay to pass a pointer to the pool of game objects (here given by the GameObjectManager). At some point there must be an interrelation between systems. And it is also okay to name that class GameObjectManager when it actually manages game objects.
However, I see other problems.
a) When each system fetches components at update time, it has no chance of managing belonging components itself in a way that is meaningful and efficient in the context of the respective sub-system, because the overall architecture prescribes how the components are stored.
b) The fact that a game object has a TransformComponent instance means that it has a spatial placement in the scene. It does not necessarily mean that it is able to move. Using a MovementSystem is one of several possibilities to alter the content of a TransformComponent. So the MovementSystem should not act on a game object just because it has a TransformComponent. (I personally use the class name "PlacementComponent" to make this clear.)
c) The player's game object is something special, of course. However, its movement is usually not, so that MovementSystem should not make a difference between the player's game object and an NPC game object.
To overcome these problems, think e.g. of the following approach:
A) There is a pool of game objects that should be added to the scene at the next opportunity. There is also a pool of game objects that should be removed from the scene at the next opportunity. It can be understood as a service of the game object management. Potentially any system located anywhere in the game loop can cause game object creation by adding a kind of job description "add game object of class X" to the belonging pool (analog for game removal). The said "opportunity to add/remove game objects" to the scene is somewhere at the very beginning of the game loop, at least before any scene related sub-system has done its update. It is nothing than the update() of the game management service. At this point the service will notify all linked sub-systems, and each of them can investigate the pools and manage their internal operational resources accordingly. So each sub-system can drive its own management structure as needed, e.g. holding pointers to all components of type Y and ignoring any game object that doesn't provide Y.
B) Sub-systems need not be all at the same level. It is more like a layered architecture, so that sub-systems on a higher layer may utilize sub-systems on a lower layer. So a MovementSystem is on a more lower layer. For example, a character is mainly controlled by the fact that a PlayerController component or AiAgentComponent is added. The sub-systems running such components may then instruct the MovementSystem when and how to handle the belonging TransformComponent data.