Me explique o que de fato acontece no event loop quando você chama await dentro de um handler de clique.

O handler roda de forma síncrona até bater no await, aí ele devolve o controle para o navegador e agenda o resto da função como uma microtask. Assim que a promise aguardada resolve, essa continuação vai para a fila de microtasks, que é drenada por completo depois da task atual e antes do próximo timer ou pintura de tela. Então o await nunca bloqueia a main thread; ele parte a função em duas.

Claro. O handler começa na main thread como qualquer outra função, e tudo até o primeiro await roda de forma síncrona. No await, a função suspende e devolve uma promise para quem a chamou, então o navegador recupera a thread e consegue pintar a tela. Quando a promise aguardada resolve, o restante da função é empurrado para a fila de microtasks, não para a fila de tasks. Isso importa porque as microtasks são drenadas por completo antes de o navegador pegar o próximo timer ou o próximo frame, então uma cadeia longa de resoluções de promise ainda consegue bloquear a renderização mesmo sem nada tecnicamente síncrono. A versão prática disso me pegou em um dashboard em que eu trabalhei. A gente estava usando await dentro de um for loop sobre umas 300 linhas, então cada requisição esperava a anterior e a página levava 12 segundos para preencher. Trocar por Promise.all com um limite pequeno de concorrência derrubou isso para menos de um segundo. Mesmo código, mesma thread, comportamento completamente diferente.