The call stack finishes what it started
The common read: a timer whose delay has already elapsed interrupts the running function to fire on time.
The call stack is where JavaScript keeps track of which function is running and who called it. One function runs at a time, and while it runs, it owns the stack completely. Nothing preempts it: not a timer, not a network response, not a click. This is run-to-completion, and it holds for every function, all the time, with no exception carved out for urgency.
"Ready" and "running" are two different states, and the gap between them is the whole lesson. setTimeout's callback became ready the moment its delay elapsed, but ready work does not join the stack. It parks in the task queue instead, and it waits there until the running function returns and the stack goes empty. Only then does the loop hand the stack to the next thing in line.
This is why the probe's timer logs last. before and after both belong to the function that's running; the timer's callback was never allowed to interrupt it, no matter how overdue it got.
