Just like with any software architecture question, the short answer is "It depends..."

Where do I put that quadtree?

Any auxiliary data structures needed by one system only should be part of that system. So if that quadtree is only used by the CollisionSystem, then you can make it part of the system.

But if that quadtree is used by many different systems, then it might make sense to extract it into an own system which does nothing but keep that quadtree up to date and also offers public interfaces for other systems to query the quadtree.

But on the other hand, if you have a dedicated MovementSystem in your architecture which is the only system allowed to move entities, then there could be potential efficiency gains to also have it manage the QuadTree. This is because the MovementSystem knows exactly which PositionComponents moved in the current tick, which allows it to decide if a branch of the quadtree needs to be updated or not.

What do I store in that quadtree?

That depends on how you are using it and how expensive it is in your particular ECS architecture to navigate between components of the same entity. If retrieving components from entity IDs is fast, then the QuadTreeSystem might only store coordinate tuples and EntityIDs (if your PositionComponent is exactly that, it might store the PositionComponent).

But if navigating between components is expensive in your architecture, you might also store any other components in the tree nodes which are frequently required by the consumers of your QuadTreeSystem.

Just like with any software architecture question, the short answer is "It depends..."

Where do I put that quadtree?

Any auxiliary data structures needed by one system only should be part of that system. So if that quadtree is only used by the CollisionSystem, then you can make it part of the system.

But if that quadtree is used by many different systems, then it might make sense to extract it into an own system which does nothing but keep that quadtree up to date and also offers public interfaces for other systems to query the quadtree.

But on the other hand, if you have a dedicated MovementSystem in your architecture which is the only system allowed to move entities, then there could be potential efficiency gains to also have it manage the QuadTree. This is because the MovementSystem knows exactly which PositionComponents moved in the current tick, which allows it to decide if a branch of the quadtree needs to be updated or not.

What do I store in that quadtree?

That depends on how you are using it and how expensive it is in your particular ECS architecture to navigate between components of the same entity. If retrieving components from entity IDs is fast, then the QuadTreeSystem might only store coordinate tuples and EntityIDs (if your PositionComponent is exactly that, it might store the PositionComponent).

But if navigating between components is expensive in your architecture, you might also store any other components in the tree nodes which are frequently required by the users of your QuadTreeSystem.