They get multiplexed across a few OS threads.

There is a scheduler which will leave goroutines that do a native (potentially blocking) call in their own thread.

The Go runtime has a built-in scheduler which historically would be called into action for possible preemption whenever an OS system call is made or could be invoked manually in Go code via runtime.Gosched(). Go 1.2 added a change allowing the scheduler to possibly be kicked off during any Go language function call which reduces the likelihood of being locked in a tight loop that never makes a system call.

There are obviously still cases where you can trap yourself into a deadlock by tight looping in code that makes no function calls at all, but it is pretty easy to detect this and adjust for it.

Is it really any more magical than how OS threads get mapped to CPU cores?