Put simply, browsers are not actually coded in JavaScript, and it is not JavaScript that manages events.
Initially, UI events are sent to the browser by the operating system, after which the browser processes these messages and schedules a task to construct the DOM Event and dispatch it, allowing the relevant JavaScript callbacks to be executed.
JavaScript is only involved in the final step. It is entirely possible to have a User Agent (UA) that does not support JavaScript but can still handle certain UI events (such as CSS pointer-events, HTML inputs, media controls, etc.)
The way this is handled varies based on the UA being used.
For a long time, in the scenario you mentioned, browsers struggled with processing clicks while the event loop was busy (the latest Internet Explorer, for instance). Modern browsers have implemented multi-process architectures that facilitate communication through Inter-Process Communication using different message queues.
Therefore, even if the "main" renderer thread is occupied carrying out tasks within the event loop, such as running JS code, other processes can run concurrently and add new tasks to the appropriate task queue.
Once the renderer thread finishes its lengthy task, it will process the newly queued task.