There is a little bit of vagueness in your question: I'm not sure whether you are asking about HTML's resize event or how CSS's @media queries respond to resizing. So I will address them separately.
HTML's resize Event
This is an event fired by window, targeted at window, and can currently only be listened to by window, although "[t]here is a proposal to allow all elements to be notified of resize changes". This is just a regular DOM event so external Javascripts may attach listeners to window and basically do whatever they want. If you are interested in how DOM events work, then you should probably just read documentation by Mozilla because they do a better job than I ever would.
CSS @media 'Reacting' to Resize Events
Notice 'Reacting' is in quotes because CSS really doesn't care if any event fired, and it isn't really reacting. You should read this excellent article by Google on how the page renderer works in browsers. Words cannot do this article justice on just how well-written it is, but I will try giving a brief summary on the part you are interested in.
TLDR;
The page renderer is an empirical loop in nature, not event-driven. It simply uses the part of CSS it needs when it needs it. In the case of @media queries, it simply checks if the queries match the current states at the time of render, and apply them if they do. It then does this all over again in the next iteration.
Slightly more specifically:
On page load, the main thread first receives the HTML, builds the DOM tree, and loads requested resources including CSS (overlooking preload scanner since it's irrelevant to the question). It then parses the CSS and calculates the computed style for each element, before passing the DOM with computed style attached to the renderer thread. The renderer performs layout, paint, composite, and sends the final composite frame to the GPU. You can read more about these individual procedures in the linked Google article.
Now the browser runs at some framerate, typically 60. So the renderer has to push 60 composite frames to the GPU every second. Obviously it's stupid to recalculate all of these for every frame, so the entire process is cached at every stage. If nothing happened between two frames, then the renderer just pushes the last calculated frame. If some event has fired between two frames, then the browser attempts to update the frame with as little work as possible. For example, if you are typing something into a textbox, there is no need to recalculate the computed style.
If an event like resize did fire during the interval between two frames however, computed style recalculation is necessary. So the main thread simply reads through the CSS, and ignores the @media queries that don't match the states for the current frame. Then it calculates the new computed style and passes that to the renderer. The renderer does its job from there.
Obviously I am overlooking a lot of performance optimisation details that exist in all modern browsers, but here's the gist of the entire process. Again, go read the Google article. It explains everything very clearly (with illustrations too!).