You'll have some code somewhere (e.g. a physics library) that knows about physics objects and stores them in some way that is efficient for things like collision and raycasting. It doesn't need to be a "system", though there would probably be a "physics system" that is responsible for keeping things in sync - so that for instance, when a Physics component is added to an entity, a corresponding object is added in the physics library (along with some way/token to associate the two representations). So, basically a system responsible for interfacing between your physics library and your "entity component system" architecture.

Any other systems (or whatever code needs to) could then call into this physics system to perform raycasts and such.

as phil says, raycasts usually test against entity locations. so your raycast would be a method of your location component system, the same way that update_location is a location component method. in the case of a raycast, it acts on the entire list of active components, its doesn't just modify a single component in the list the way update_location might. raycast is a form of list search. in an ECS, the list of location components would be the list to search. so raycast should be a location component method.

so whenever some high level controlling code needs to do a raycast - say LOS check for sneak mode - it calls the location system with a starting location and direction for the cast, and the location system returns what they hit.

note that you can also do raycasts vs geometry, in which case it would be the list of renderable meshes, not the entity locations, that would be used.