Depending on the language, GC is either implemented in userspace using linear memory, or using the new GC extension to webassembly. The latter has some restrictions that mean not every language can use it and it's not a turnkey integration (you have to do a lot of work), but there are a bunch of implementations now that use wasm's native GC.
If you use wasm's native GC your objects are managed by the WASM runtime (in browsers, a JS runtime).
For things like goroutines you would emulate them using wasm primitives like exception handling, unless you're running in a host that provides syscalls you can use to do stuff like stack switching natively. (IIRC stack switching is proposed but not yet a part of any production WASM runtime - see https://webassembly.org/features/)
Based on what I read in a quick search, what Go does is generate each goroutine as a switch statement based on a state variable, so that you can 'resume' a goroutine by calling the switch with the appropriate state variable to resume its execution at the right point.
currently CPython's WASI build does not have asyncio support out of the box (at least according to [0]). This is, by my understanding, downstream of asyncio implementations in the standard library being built off of primitives around sockets and the like. And WASI, again by my understanding, does not support sockets.
In a browser environment there are theoretically ways you could piggyback off of the async support in the native ecosystem. But CPython is written to certain systems, so you're talking about CPython patches.
BUT the kind of beautiful thing is you can show up with your own asyncio event loop! So for example Pyodide just ships its own asyncio event loop[1]. This is possible thanks to Python's async infra just being built off of its generator concepts. async/await is, in itself, not something that "demands" I/O, just asyncio is.
