Explícame qué ocurre de verdad en el event loop cuando llamas a await dentro de un manejador de clic.

El manejador se ejecuta de forma síncrona hasta que llega a await, entonces devuelve el control al navegador y programa el resto de la función como una microtarea. Cuando la promesa esperada se resuelve, esa continuación entra en la cola de microtareas, que se vacía por completo tras la tarea actual y antes del siguiente temporizador o pintado. Así que await nunca bloquea el hilo principal; parte la función en dos.

Claro. El manejador arranca en el hilo principal como cualquier otra función, y todo lo anterior al primer await se ejecuta de forma síncrona. En el await, la función se suspende y devuelve una promesa a quien la llamó, así que el navegador recupera el hilo y puede pintar. Cuando la promesa esperada se resuelve, el resto de la función se empuja a la cola de microtareas, no a la de tareas. Eso importa porque las microtareas se vacían del todo antes de que el navegador coja el siguiente temporizador o el siguiente fotograma, así que una cadena larga de resoluciones de promesas puede seguir bloqueando el renderizado aunque técnicamente nada sea síncrono. La versión práctica de esto me mordió en un panel en el que trabajé. Hacíamos await dentro de un bucle for sobre unas 300 filas, así que cada petición esperaba a la anterior y la página tardaba 12 segundos en llenarse. Pasar a Promise.all con un pequeño límite de concurrencia lo bajó por debajo de un segundo. El mismo código, el mismo hilo, un comportamiento completamente distinto.